[toc]
春节后的1次小问题#
春节假期之后，我回到工位，发现开发用的3台实验机器中，有1台使用EIP（外网ip）登不上了， 只能使用vpn去连接小网ip登录。
咨询了一下物理机管理员，说假期因为实验室维护, 重启了机器，线路正常， 应该是机器的网络配置之前只临时生效，重启后就没了，让我自己查查看。
于是只能努力从大脑里挖掘有关计算机网络的回忆， 发现没啥好思路，去内网搜了下类似问题，才知道路由会影响eip， 对比了1下失效机器 和其他正常机器的路由表配置， 才发现缺少到NAT网关的路由，导致报文无法往回发。
修改了一波路由配置后 便通了。
反思#
这时候我才发现删减改查的业务做得多了，很多经典知识都忘记了。
心想要不要去找本书系统回忆下网络知识？
但是又懒得去番以前的教材，谢老的《计算机网络》?
算了，学生时代它那从物理层开始，再到链路层的超长阴影记忆尤新。
于是整了本经典的《TCP/IP详解》，抱着学习者的心态重新学习了1下。
可是，决定开始看之前，又犹豫了一下：
业务需求写完了吗？sql性能优化到最佳了吗？ 模块可信、稳健了吗？有必要费时间看这些烂大街的，应届生们面经必背的常见知识？
换言之，作为浮于业务应用上层的java开发小兵，我需要去思考1个问题：当我们学习TCP/IP时，我们在学什么？
抛去以往的功利、应试等心态，我抱着这个问题看完了全书，给了我自己的几个思考
一、学习协议格式的常见设计思路#
IP和TCP的章节里，分别花了大章节，讲述协议首部内容。
学生时代很反感这个东西，感觉就是为了出计算题和记忆题， 我们又不去改报文，看这啥用。
然而工作后，发现这是计算机初学者们，最早能接触到的通讯协议格式设计思想了。
以IP报文格式为例， 可以看到
有 首部长度、总长度，， 还有用于处理报文切分的字段，， 以及校验字段，避免首部错误。
而如果自己需要设计一套以二进制流为基础的应用层通信协议，很大概率，也要包含以上的内容。
例如我们怎么确定数据多长，怎么保证数据不被篡改，怎么分多次而保证不会乱， 这些都是常见的协议设计重点问题。 而这些问题的解决思路，就可以从TCP、IP等经典协议中初见端倪。
二、学习图算法的应用#
数据结构里，最让很多人头疼的就是图那章了。然而图的内容却是应用最强力的东西。
IP层路由概念的设计，简直是图算法的完美应用常见：
- 路由表就是很经典的图数据结构设计。
- 如何动态更新最短路， RIP和OSPF协议也分别给了我们思路
甚至路由表里对子网最长匹配的应用，也用到了前缀树算法（线索树），让人感觉oj网站上算法题都亲切了不少。
三、学习可靠性流程的设计#
当重看TCP协议的握手挥手设计，以及重连机制，我还是会感到惊叹连连。
于是给自己提了个问题，如果不考虑TCP的可靠性，基于应用层，设计一套能稳定可靠的消息交互程序，我能想到有哪些要考虑的地方吗？基于那章，我大概想到了是以下几点
- 如何能确保对方收到了我的信息？——TCP引入了ack响应
- 怎样算两边开始正式交互？——能够证明两边的网络通道都能通，所以你我各需要1次ack响应来相互证明。
- 怎么直到我的消息丢了？——每次消息发出，都有个定时器检查，超时时间内没收到，就会重发，直到到达次数上限，则认为超时
- 超时时间怎么确定？——根据每次的时间样本定时更新
- 超时后怎么办？——拥塞避免算法
- 发少了太慢，发多了会阻塞，怎么确定1次可以发多少？——慢启动算法
可以看到TCP协议里，基本把上述可靠性的设计问题都考虑到了，而且到了及其细致的地步。当你有这类需求时，不妨第一时间回忆下TCP的优秀之处