• 传输层有2个协议
• TCP（Transmission Control Protocol）传输控制协议

• UDP（User Datagram Protocol）用户数据协议

  
  

UDP-数据格式

• UDP是无连接的，减少了建立和释放连接的开销
• UDP尽最大能力交付，不保证可靠交付
• 因此不需要维护一些复杂的参数，首部只有8个字节（TCP的首部至少有20个字节）

• UDP长度：占16位，首部的长度 + 数据的长度

  
  

UDP-校验和（Checksum）

• 校验和的计算内容: 伪首部 + 首部 + 数据

• 伪首部：仅为计算校验和时起作用，并不会传递给网络层

  
  摘抄至MJ的网络协议
• 从上图可以看出，伪首部由：源IP地址，目的IP地址，UDP长度等信息组成，伪首部与首部，数据参与计算出校验和，最终成一个首部，
  首部+数据组成UDP的传输数据，再传递给网络层。

TCP - 数据格式

TCP报文段

TCP - 标志位（Flags）

• URG（Urgent）：当URG = 1时，紧急指针字段才有效，表明当前报文有紧急数据，应优先尽快传送
• ACK（Ackownledgment）：当ACK = 1时，确认字段才有效
• PSH（Push）
• RST（Reset）：当RST = 1 时，表明链接中严重差错，必须释放连接，然后再重新建立连接
• SYN(Synchronization): 当SYN = 1, ACK = 0时，表明这是一个建立连接的请求；若对方同意建立连接，则回复 SYN = 1， ACK = 1
• FIN (Finish): 当FIN = 1 时，表明数据已经发送完毕，要求释放连接

TCP - 序号、确认窗口、窗口

• 序号（Sequence Number）

  • 占4个字节
  • 首先，在传输过程的每一个字节都会有一个编号
  • 在建立连接之后，序号代表：这一次给对方的TCP数据部分的第一个字节的编号

• 确认号（Ackowledgment Number）

  • 占4字节
  • 在建立连接后，确认号代表：期待对方下一次传过来的TCP数据部分的第一个字节的编号

• 窗口（Window）

  • 占2字节
  • 这个字段有流量控制功能，用以告知对方下一次允许发送的数据大小（字节单位）

TCP的几个要点

• 可靠传输
• 流量控制
• 拥塞控制
• 连接管理：建立连接，释放连接

TCP - 可靠传输 - 停止等待ARQ协议

• 超时重传
• 确认丢失
• 确认迟到

• ARQ（Automatic Repeat - reQuest）, 自动重传请求

  
  

• 如果有个包重传了N次还是失败，会一直持续重传到成功为止么？取决于系统的设置，比如有些系统，重传5次还未成功就会发送reset报文断开TCP连接

TCP - 可靠传输 - 连续ARQ协议 + 滑动窗口

摘自MJ网络协议

• 停止等待协议：发送一个分组就停止发送等待确认

• 连续ARQ协议和滑动窗口协议：发送窗口中的分组连续发送，发送完毕后，停止等待确认

• 问题：如果接收 窗口最多能4个包，但发送方只了 2个包，接收方如何确定后面还有 没2个包？

  • 等待一定时间后没有第 3个包
  • 就会返回确认收到 2个包给发送方

TCP - 可靠传输 - SACK（选择性确认）

• 在TCP 通信过程中，如果发送序列中间某个数据包丢失（比1、2、3、4、5中的 3丢失了）
• TCP 会通过重传最后确认的分组续（是 2，会重传 3、4、5）
• 这样原先已经正确传输的分组也可能重复发送（比如 4、5），降低了 TCP 性能
• 为改善上述情况，发展出了 SACKSACK（Selective acknowledgment acknowledgment，选择 性确认）技术
  • 告诉发送方哪些数据丢失，哪些数据已经提前收到
  • 使TCP 只重新发送丢失的包（比如 3），不用发送后续所有的分组（比如 4、5）

TCP - 可靠传输 - SACK（选择性确认）

摘自MJ网络协议

• SACK 信息会放在 TCP 首部的选项部分

  • Kind ：占 1字节。值为 5代表这是 SACK 选项
  • Length ：占 1字节。表明 SACK 选项一共占用多少字节
  • Left Edge Edge：占 4字节，左边界
  • Right Edge ：占 4字节，右边界

• 一对边界信息需要占用 8字节，由于 TCP 首部的选项分最多 40 字节，所以

• SACK 选项最多携带 4组边界信息

• SACK 选项的最大占用字节数 = 4 * 8 + 2 = 34

• 问题：为什么选择在传输层就将数据“大卸八块”分成多个段，而不是等到网络再片递给链路？

  • 因为可以提高重传的性能，可靠传输在层进行控制，如果在传
    输层不分段，一旦出现数据丢失整个的都得重传； 如果在传输层分了段，一旦出现数据丢失，只需要重传丢失的那些段即可

• 总结: TCP的可靠传输的方式有：停止等待ARQ（超时重传，确认等待，确认迟到），连续ARQ + 滑动窗口，选择性确认等方式

TCP - 流量控制

• 如果接收方的缓存区满了，发送还在疯狂着数， 接收方只能把到的数据包丢掉，大量会极着浪费网络资源，所以要进行流量控制
• 什么是流量控制？： 让发送方的速率不要太快，接收来得及处理
• 原理：
  • 通过确认报文中窗口字段来控制发送方的速率
  • 发送方的窗口大小不能超过接收方给出窗口大小
  • 当发送方收到接收窗口的大小为 0时，发送方就停止发送数据

• 流量控制的特殊情况
  • 一开始，接收方给发送了 0窗口的报文段
  • 后面，接收方又有了一些存储空间给发送的非 0窗口的报文段丢失了
  • 发送方的窗口一直为零，双陷入僵局
• 解决方案
  • 当发送方收到 0窗口通知时，这发送方停止报文
  • 并且同时开启一个定器，隔段间就发测试报文去询问接收方最新的窗口大小
  • 如果接收的窗口大小还是为 0，则发送方再次刷新启动定时器

TCP - 拥塞控制

• 拥塞控制
  • 防止过多的数据注入到网络中
  • 避免网络中的路由器或链过载
• 拥塞控制是一个全局性的过程
  • 涉及到所有的主机、路由器
  • 以及与降低网络传输性能有关的所因素
  • 是大家共同努力的结果
• 相比而言，流量控制是点对点通信的控制

TCP - 拥塞控制 - 方法

• 慢开始（ slow start start，慢启动）
• 拥塞避免（ congestion avoidance avoidance）
• 快速重传（ fast retransmit retransmit）
• 快速恢复（ fast recovery recovery）
• 几个缩写
  • MSS （Maximum Segment Size）：每个段最大的数据部分大小，在建立连接时确定
  • cwnd （congestion window）：拥塞窗口
  • rwnd（receive window）：接收窗口
  • swnd （send window）：发送窗口
  • swnd = min(cwnd, rwnd)

TCP - 拥塞控制 - 慢开始

慢开始-摘自MJ网络协议
慢开始-摘自MJ网络协议

• cwnd（拥塞窗口）的初始值比较小，然后随着数据包被接收方确认（ACK），cwnd就成倍增长

TCP - 拥塞控制 - 拥塞避免

拥塞避免-摘自MJ网络协议

• ssthresh(slow start threhold):慢开始阈值，cwnd达到阈值后，以线性方式增加
• 拥塞避免（加法增大）：拥塞窗口缓慢增大，以防止网络过早出现拥塞
• 乘法减小：只要网络出现拥塞，把ssthresh减为拥塞峰值的一半，同时执行慢开始算法（cwnd又恢复到初始值）
• 当网络频繁出现拥塞时，ssthresh值就下降很快

TCP - 拥塞控制 - 快重传

• 接收方
  • 每收到一个失序的分组后就立即发出重复确认
  • 使发送方及时知道分组没有到达
  • 而不要等到自己发送数据时才进行确认
• 发送方
  • 只要连续收到三个重复确认，就应当立即重传对方尚未收到的报文段

  • 而不必继续等到重传计时器到期后再重传

    
    快重传-摘自MJ网络协议

TCP - 拥塞控制 - 快恢复

• 当发送方连续收到三个重复确认，说明网络出现拥塞
• 就执行“乘法减小”算，把 ssthresh 减为拥塞峰值的一半
• 与慢开始不同之处是现在不执行慢开始算法，即 cwnd 现在不恢复到初始值
  • 而是把 cwnd 值设置为新的 ssthresh 值（减小后的值）
  • 然后开始执行拥塞避免算法（“加法增大")，使拥塞窗口缓慢线性增大

快重传+快恢复

TCP - 拥塞控制 - 发送窗口的最大值

• 发送窗口的最大值： swnd = min(cwnd, rwnd)
• 当rwnd < cwnd 时，是接收方的能力限制发送窗口最大值
• 当cwnd < rwnd 时，则是网络的拥塞限制发送窗口最大值

TCP - 序号、确认号

• 序号：TCP数据段的第一个字节位置

• 确认号：TCP数据下一次发送的字节位置

  
  

TCP - 建立连接 - 3次握手

3次握手的过程

• 状态解读

  • CLOSED：client 处于关闭状态
  • LISTEN ：server 处于监听状态，等待 client 连接
  • SYN -RCVD：表示 server 接受到了 SYN 报文，当收到 client 的ACK 报文后，它会进入到 ESTABLISHED 状态
  • SYN -SENT ：表示 client 已发送 SYN 报文，等待 server 的第 2次握手
  • ESTABLISHED：表示连接已经建立

• 前2次握手的特点

  • SYN 都设置为 1
  • 数据部分的长度都为 0
  • TCP 头部的长度一般是 32 字节， 固定头部： 20 字节，选项部分： 12 字节
  • 双方会交换确认一些信息，比如 MSS 、是否支持 SACK 、Window scale （窗口缩放系数）等， 这些数据都放在了 TCP 头部的选项分中（ 12 字节）

• 面试题:TCP为什么建立连接的时候，要进行 3次握手？ 2次不行么？

  • 主要目的：防止 server 端一直等待，浪费资源
  • 如果建立连接只需要 2次握手，可能会出现的情况
    • 假设 client 发出的第一个连接请求报文段，因为网络延迟在释放以后某时间才到达 server
  • 本来这是一个早已失效的连接请求，但 server 收到此失效的请求后，误认为是 client 再次发出的一个新连接请求
  • 于是 server 就向 client 发出确认报文段，同意建立连接
  • 如果不采用“ 3次握手”，那么只要 server 发出确认，新的连接就建立了

• 由于现在 client 并没有真正想连接服务器的意愿，因此不会理睬 server 的确认，也不会向 server 发送数据

• 但server 却以为新的连接已经建立，并一直等待 client 发来数据， 这样server 的很多资源就白浪费掉了

• 采用“三次握手”的办法可以防止上述现象发生

• 例如上述情况， client 没有向 server 的确认发出， server 由于收不到确认，就知道 client 并没有要求建立连接

• 面试题: 第3次握手失败了，会怎么处理？

  • 此时 server 的状态为 SYN -RCVD，若等不到 client 的ACK，server 会重新发送 SYN+ACK 包
  • 如果 server 多次重发 SYN+ACK 都等不到 client 的ACK，就会发送 RST 包，强制关闭连接

TCP释放连接 - 4次挥手

TCP-释放连接 - 4次挥手

• FIN -WAIT-1：表示想主动关闭连接,向对方发送了 FIN 报文，此时进入到 FIN -WAIT-1状态

• CLOSE-WAIT：表示在等待关闭， 当对方发送 FIN 给自己，会回应一个 ACK 报文给对方，此时则进入到 CLOSE-WAIT 状态， 在此状态下，需要考虑自己是否还有数据发送给对方，如果没FIN 报文给对方

• FIN -WAIT-2：只要对方发送 ACK 确认后，主动方就会处于 FIN -WAIT-2状态，然后等待对方发送 FIN 报文

• CLOSING：一种比较罕见的例外状态,表示你发送 FIN 报文后，并没有收到对方的 ACK 报文，反而却也收到了对方的 FIN 报文, 如果双方几乎在同时准备关闭连接的话，那么就出现了发送 FIN 报文的情况，也即会出现 CLOSING 状态, 表示双方都正在关闭连接

• LAST-ACK：被动关闭一方在发送 FIN 报文后，最等待对方的 ACK 报文,当收到 ACK 报文后，即可进入 CLOSED 状态了

• TIME -WAIT：表示收到了对方的 FIN 报文，并发送出了 ACK 报文，就等 2MSL 后即可进入 CLOSED 状态了, 如果 FIN -WAIT-1状态下，收到了对方同时带 FIN 标志和 ACK 标志的报文时, 可以直接进入到 TIME -WAIT 状态，而无须经过 FIN -WAIT-2状态

• CLOSED：关闭状态

TCP - 释放连接细节

• TCP/IP 协议栈在设计上，允许任何一方先发起断开请求。
• client 发送 ACK 后，需要有个 TIME -WAIT 阶段，等待一时间后再真正关闭连接
• 一般是等待 2倍的 MSL （Maximum Segment Lifetime Lifetime，最大分段生存期）
• MSL 是TCP 报文在 Internet 上的最长生存时间
• 每个具体的 TCP 实现都必须选择一个确定的 MSL 值， RFC 1122 建议是 2分钟
• 可以防止本次连接中产生的数据包误传到下一次连接中（因为本次连接中的数据包都会在 2MSL 时间内消失了）
• 如果 client 发送 ACK 后马上释放了， 然又因为网络原server 没有收到 client 的ACK，server 就会重发 FIN，这时可能出现的情况是：
  • client 没有任何响应，服务器那边会干等甚至多次重发 FIN ，浪费资源
  • client 有个新的应用程序刚好分配了同一端口号，收到 FIN 后马上开始执行断连接的操作，本来 它可能是想跟 server 建立连接的

面试题： 为什么释放连接的时候，要进行 4次挥手？

• TCP 是全双工模式

• 第1次挥手：当 主机 1发出 FIN 报文段时

  • 表示 主机 1告诉 主机 2，主机 1已经没有数据要发送了，但是此时 主机 1还是可以接受来自 主机 2的数据

• 第2次挥手：当 主机 2返回 ACK 报文段时

  • 表示 主机 2已经知道 主机 1没有数据发送了，但是 主机 2还是可以发送数据到 主机 1的

• 第3次挥手：当主机 2也发送了 FIN 报文段时

  • 表示 主机 2告诉 主机 1，主机 2已经没有数据要发送了

• 第4次挥手：当主机 1返回 ACK 报文段时

  • 表示 主机 1已经知道 主机 2没有数据发送了。随后正式断开整个 TCP 连接

• 有时候在使用抓包工具的，可能只会看到“ 3次“挥手

• 这其实是将第 2、3次挥手合并了

• 当server 接收到 client 的FIN 时，如果 server 后面也没有数据要发送给 client 了

• 这时， server 就可以将第 2、3次挥手合并，同时告诉 client 两件事

  • 已经知道 client 没有数据要发
  • server 已经没有数据要发了