TCP(UDP)/IP 作为网络通讯协议最基础和常用的协议, 讨论的非常多, 本文对TCP/IP 做一个简单的回顾
1、网络协议模型
链路层 (对应的是硬件部分, 在 7层模型中对应 链路层和物理层) 网络层 IP协议所在的层 (7 层模型中的 网络层) 传输层 TCP协议所在的层 ( 7 层模型的 传输层) 应用层 HTTP、FTP 协议所在的层 ( 7 层模型上三层)
其实层次模型非常好记, 最底层肯定是要处理硬件的转换； 接着就是需要寻址, 设备互联; 连通了设备, 考虑数据发送的各种(比如 流量控制)；最后在这个基础上可以设计任意协议。 这也给了我们 在设计程序 交互的思路、平台框架的思路，先基础设施、然后功能叠加。
2、TCP 建链(握手)过程 和 关闭链接(挥手)过程
TCP 三次握手 Client A sync=j ->Server B 进入SYN_SEND状态 Server B sync=j+1 sync=k - >Client A 进入SYN_RECV 状态 Client A sync=k+1 ->Server B 共同进入 ESTABLISHED状态
TCP 四次挥手 Client A Fin(i) -> Server B Server B Ack(i+1) -> Client A Server B Fin(j) - > Client A Client A Ack(j+1) -> Server B
关闭时，采用四次而不是三次，因为A关闭时，此时 B 不一定数据都发完了，所以B要另外等一下再发自己的关闭消息
3、IP 路由过程
从前面的描述,可以知道 每一层协议都会在消息头部加上自己的内容, 比如TCP层加上端口号, IP层会加上IP地址, 链路层则会加上MAC地址。 那通讯的两个节点 A 怎么知道 如何到 B呢？
I、网段内的路由 - ARP 对于 一层设备(HUB)组合的网络, 不能识别IP和MAC都是广播的。 对于 二层设备(交换机)组合的网络。 a、A 发出广播, 寻找目标IP的 MAC地址, 并附上自己的MAC地址。 b、交换机收到广播, [更新自己的MAC地址表], 转发广播请求 c、B收到广播响应消息, 给A回一个消息 d、交换机收到消息 , [更新自己的MAC地址表], 找到A 的MAC地址对应的端口,把消息给A e、A收到消息, 得到B的MAC地址, 缓存在本地。 寻址结束
II、不同网段的路由 - RIP/BGP 如果是跨网段的路由, 则需要用到 三层交换设备(路由器), 识别IP地址 寻址过程和 交换机的类似, 只是中间过程, 路由器需要不断的接力, 把数据在 路由器网络间传递, 到达目标网段后, 再由当前路由器分发到具体的节点(通过查找ARP缓存或者广播ARP消息) 路由器之间的 路由过程？ 通过IP 和 掩码构建路由表。这个路由的构成, 就是通过 RIP协议广播得到的。 a、每隔一段时间 广播一下自己的路由表；为了防止广播风暴, 时间间隔可以设置随机 b、收到的路由器更新自己的路由表 c、防止路由相互更新循环错误, 规定最大不能超过 15跳(每经过一个路由器, 为一跳),超过 15跳, 认为路径不可达
4、数据发送
I、发送内容 a、IP报文
b、TCP 报文
c、UDP 报文
IP报文的数据段就是TCP/UDP报文, 理论上一个IP报文的最大单包大小可达 65535(包含报文头), 实际上因为在传输过程中 会对IP包分片为 MTU；而以太网的MTU值为 1500；实际使用中, 一般单包长度设置 < 1500 - 20(IP头) - 20(TCP头) 可以使用 Wireshark 抓包看每个报文, 网络程序开发时, 查看报文是非常重要的手段。 重点关注 报文内容| 报文长度 | 五元组(源和目标的IP地址、端口, 协议类型)
II、流量(拥塞)控制 - 滑动窗口协议 传输的双方非常类似于传统的 生产-消费模型；发送方就是 生产者，接收方就是 消费者。 在生产 - 消费模型的典型设计中, 一般会有一个 缓存队列, 生产者不断推送数据到队列，消费者不断从队列取数据进行处理。当两者的处理速率不一致时, 就会出现 要么队列充满, 生产者等待, 要么队列为空, 消费者等待。
滑动窗口协议也采用了类似的思路。 在发送方和消费方都有各自的缓存 - 类似于 队列。 a、在建链时, 协商每次发送的数据大小 (窗口 window); 以后每次接收方都反馈一个 窗口通知, 告知可接受的窗口大小; 如果为 0 , 发送者停止发送 b、发送方和接收方不断调整窗口的大小, 当出现拥塞时, 发送方减小窗口大小; 如果接收方处理加快,则窗口也加大 这样就实现了 动态调整 高效的 数据发送和接受
III、TCP VS UDP TCP是面向连接的协议, 通过报文, 可以看到 TCP 有确认措施, 保证数据能够安全发送和接受, 没有确认的, 会重发; 通过流量控制的窗口, 可以保证 数据有序的发送. UDP是无连接的协议, 通过报文可知, 发送方只管发送, 不管是否收到, 也不管顺序。 但因为, 缺少交互的确认过程, 所以 UDP 的发送效率要高于TCP。
一般情况下, 如果需要更高效率的发送可以使用UDP, 而且UDP并没有想象的有那么多丢包。 实际使用过程中, 可以由应用, 在数据里面增加 数据序号, 从而实现丢包重发和排序。
