- 传输层有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 - 标志位（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协议 + 滑动窗口
停止等待协议：发送一个分组就停止发送等待确认
连续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（选择性确认）
-
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 - 拥塞控制 - 慢开始
- cwnd（拥塞窗口）的初始值比较小，然后随着数据包被接收方确认（ACK），cwnd就成倍增长
TCP - 拥塞控制 - 拥塞避免
- 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次握手
-
状态解读
- 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次挥手
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 已经没有数据要发了
