传输层（UDP协议，TCP协议三次握手、四次挥手）

传输层有2个协议

• TCP(Transmission Control Protocol)，传输控制协议
• UDP(User Datagram Protocol)，用户数据协议

UDP —— 数据格式

• UDP是无连接的，减少了建立和连接的开销
• UDP尽最大能力交付，不保证可靠交付

        因此不需要维护一些复杂的参数，首部只有8个字节（TCP的首部至少20个字节）

• UDP长度

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

UDP —— 检验和（Checksum）

检验和的计算内容：伪首部 + 首部 + 数据

伪首部（使检验能力更强）：仅在计算检验和时起作用，并不会传递给网络层

端口（Port）

• UDP首部中端口是占用2字节（可以推测出端口号的取值范围是：0~65535）
• 客户端的源端口是临时开启的随机端口，服务器就不是了
• 防火墙可以设置开启/关闭某些端口来提高安全性

常用命令行

netstat -an: 查看被占用的端口

netstat -anb: 查看被占用的端口、占用端口的应用程序

telnet 主机 端口：查看是否可以访问主机的某个端口

（安装telnet：控制面板 -- 程序 -- 启用或关闭Windows功能 -- 勾选“Telnet Client” -- 确定 ）

---

TCP数据格式

数据偏移

• 占4位，取值范围：0x0101~0x1111（20~60）
• 乘以4：首部长度
• 首部长度是20~60字节

保留

• 占6位，目前全为0

TCP --- 小细节

有些资料中，TCP首部的保留（Reserved）字段占3位，标志（Flag）字段占9位（Wireshark中也是如此）

•  UDP的首部中有16位的字段记录了整个UDP报文的长度（首部+数据）
• 但是，TCP的首部中仅仅有4位的字段记录了TCP报文的首部长度，并没有字段记录TCP报文的数据长度
• 分析：

UDP首部中占16位的长度字段是冗余的，纯粹是为了保证首部是32bit对齐

TCP/UDP的数据长度，完全可以由IP数据包的首部推测出来 

传输层的数据长度 = 网络层总长度 - 网络层的首部长度 - 传输层的首部长度

网络层数据长度 = 网络层总长度 - 网络层的首部长度 

而网络层数据是传输层传下来的数据

TCP —— 校验和（Checksum）

和UDP一样，TCP校验和的计算内容：伪首部 + 首部 + 数据

伪首部：占用12字节，仅在计算检验和时起作用，并不会传递给网络层

TCP —— 标志位（Flags）

URG（Urgent）

• 当URG=1时，紧急指针字段才有效。表明当前报文段中有紧急数据，应优先尽快传送

ACK（Acknowledgment）

• 当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数据部分的第一个字节的编号

确认号（Acknowledgment Number）

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

窗口（Window）

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

TCP的几个要点

• 可靠传输
• 流量控制
• 拥塞控制
• 连接管理

        建立连接

        释放连接

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

（发送方给接收方发数据，没有收到发送方发来的数据，接收方就不会给发送方一个ACK信号，如果发送方超时没有接收到ACK信号，发送方就会重新发）

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

 

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

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

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

现在假设每一组数据是100个字节，代表一个数据段的数据，每一组给一个编号

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

• 在TCP通信过程中，如果发送序列中间某个数据包丢失（比如1、 2、 3、 4、 5中的3丢失了）
• TCP会通过重传最后确认的分组后续的分组（最后确认的是2，会重传3、 4、 5）
• 这样原先已经正确传输的分组也可能重复发送（比如4、 5），降低了TCP性能

为改善上述情况，发展出了SACK（Selective acknowledgment，选择性确认）技术
告诉发送方哪些数据丢失，哪些数据已经提前收到
使TCP只重新发送丢失的包（比如3），不用发送后续所有的分组（比如4、 5）

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

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

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

• SACK选项最多携带4组边界信息
• SACK选项的最大占用字节数 = 4 * 8 + 2 = 34

 （左边界有边界告诉发送方哪些是收到了的）

抓包来试试

可以发现，两个值相减得到的数是一样的，那么说明这是同一个请求。 

（一开始建立请求的时候，这两个值相减就确定了一个值，之后就是Sequence Number(raw)减去这个值，就是Sequence Number的值了，所以，一开始Sequence Number是不知道的）

疑问： 若有个包重传了N次还是失败，会一直持续重传到成功为止吗？

这个取决于系统的设置，比如有些系统，重传5次还未成功就会发送reset报文（RST）断开TCP连接。

 

思考一个问题：

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

因为可以提高重传的特性

需要明确的是：可靠传输是在传输层进行控制的

如果在传输层不分段，一旦出现数据丢失，整个传输层的数据都得重传

如果在传输层分了段，一旦出现数据丢失，只需重传丢失的那些段即可

---

TCP —— 流量控制 

如果接收方的缓存区满了，发送方还在疯狂的发送数据

接收方只能把收到的数据包扔了，大量的丢包会极大的浪费网络资源

所以要进行流量控制

• 什么是流量控制？

        让发送方的速率不要太快，让接收方来得及接收处理

原理：

• 通过确认报文中窗口字段来控制发送方的发送速率
• 发送方的发送窗口大小不能超过接收方给出的窗口大小
• 当发送方接收到窗口的大小为0时，发送方就会停止发送数据

TCP —— 流量控制（特殊情况） 

有一种特殊情况

一开始，接收方给发送方发送了0窗口的报文段，后面，接收方又有了一些存储空间，给发送方发送了非0窗口的报文丢失了，发送方的发送窗口一直为0，双方陷入僵局。

解决方案:

• 当发送方收到0窗口通知时，这时发送方停止发送报文
• 并且同时开启一个定时器，隔一段时间就发个测试报文去询问接收方最新的窗口大小
• 如果接收的窗口大小还是为0，则发送方再次刷新启动定时器 

---

TCP —— 拥塞控制

拥塞控制

• 防止过多的数据注入到网络中
• 避免网络中的路由器或链路过载

拥塞控制是一个全局性的过程

• 涉及到所有的主机、路由器
• 以及与降低网络传输性能有关的所有因素
• 是大家共同努力的结果

相比而言，流量控制是点对点通信的控制

TCP —— 拥塞控制 —— 方法 

• 慢开始（slow start,慢启动）
• 拥塞避免（congestion avoidance）
• 快速重传（fast retransmit）
• 快速恢复（fast recovery）

理解几个缩写

MSS（Maximum Segment Size）：每个段最大的数据部分大小

• 在建立连接时确定

cwnd(congestion window):拥塞窗口（在发送方那）

rwnd(receive windows):接收窗口

swnd(send window):发送窗口

• swnd = min(cwnd,rwnd)

TCP —— 拥塞控制 —— 慢开始

cwnd的初始值比较小，然后随着数据包被接受方确认（收到一个ACK），cwnd就成倍增长（指数级增长）

TCP —— 拥塞控制 —— 拥塞避免

• ssthresh（slow start threshold）：慢开始阈值， cwnd达到阈值后，以线性方式增加
• 拥塞避免（加法增大）：拥塞窗口缓慢增大，以防止网络过早出现拥塞
• 乘法减小：只要网络出现拥塞（通过丢包判断是否拥塞），把ssthresh减为拥塞峰值的一半，同时执行慢开始算法（cwnd又恢复到初始值）

        当网络出现频繁拥塞时， ssthresh值就下降的很快

TCP —— 拥塞控制 —— 快重传

接收方

• 每收到一个失序的分组后就立即发出重复确认
• 使发送方及时知道有分组没有到达
• 而不要等待自己发送数据时才进行确认

发送方

• 只要连续收到三个重复确认（总共4个相同的确认），就应当立即重传对方尚未收到的报文段
• 而不必继续等待重传计时器到期后再重传

TCP —— 拥塞控制 —— 快恢复

当发送方连续收到三个重复确认，说明网络出现拥塞

• 就执行“乘法减小”算法，把ssthresh减为拥塞峰值的一半

与慢开始不同之处是现在不执行慢开始算法，即cwnd现在不恢复到初始值

• 而是把cwnd值设置为新的ssthresh值（减小后的值）
• 然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大

TCP —— 拥塞控制 —— 快重传 + 快恢复

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

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

TCP —— 序号、确认号

（紫色：客户端：蓝色：服务器）

①（客户端给服务器发建立请求连接）：开始建立连接时候（发送的第一个请求）只发送首部，没有数据部分，所以相对值seq = 0，对方没有发东西给接收方，所以相对ack = 0

②（服务器回应客户端）：依然只有头部，没有数据，相对seq = 0；相对ack = 1，是接收方给发送方一个确认，希望客户端发送序号为1的数据。

③：seq = 1，是为了响应服务器发送过来的相对ack（ack = 1），ack = 1，希望服务器下次发送序号为1的数据。

④：也是客户端给服务器发东西，ack是对上一次服务器发送过来的东西的一个响应，所以相当于③、④都是对②的一个回应。

 

第n个包的序号：前面n-1个包的总长度 + 1

序号确认号 —— 相对

序号确认号 —— 原生 

TCP —— 建立连接 —— 3次握手 

TCP —— 建立连接 —— 状态解读 

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

TCP —— 建立连接 —— 前2次握手特点

• SYN都设置为1
• 数据部分的长度都为0
• TCP头部的长度一般是32字节

        固定头部：20

        选项部分：12

• 双方会交换确认信息

        比如MSS、是否支持SACK、Window scale（窗口缩放系数）等

一个细节

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包，强制关闭连接

 

补充一点：

在实际开发中，如果服务器已经进入ESTABLISHED状态，服务器就在等客户端发东西给它。如果15s内还没有数据发送过来，服务器就会主动断开连接，但是客户端为了不断开连接，客户端就会每隔5s发送一个数据包，证明还不想断开连接。（连接保活，每隔一段时间发送数据包，每隔5s发一个包（心跳包）） 

TCP —— 释放连接 —— 4 次挥手 

TCP —— 释放连接 —— 状态解读

• 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：关闭状态

由于有些状态的时间比较短暂，所以很难用 netstat 命令看到，比如SYN-RCVD、 FIN-WAIT-1等

（ 好家伙，我竟然看到了FIN-WAIT-1，不过也是我试了好几次才看到的）

TCP —— 释放连接 —— 细节

• TCP/IP协议栈在设计上，允许任何一方先发起断开请求。这里演示的是client主动要求断开
• client发送ACK后，需要有个TIME-WAIT阶段，等待一段时间后，再真正关闭连接
• 一般是等待2倍的MSL（Maximum Segment Lifetime，最大分段生存期）

MSL是TCP报文在Internet上的最长生存时间
每个具体的TCP实现都必须选择一个确定的MSL值， RFC 1122建议是2分钟

可以防止本次连接中产生的数据包误传到下一次连接中（因为本次连接中的数据包都会在2MSL时间内消失了） 

• 如果client发送ACK后马上释放了，然后又因为网络原因， server没有收到client的ACK， server就会重发FIN

        这时可能出现的情况是
        ① client没有任何响应，服务器那边会干等，甚至多次重发FIN，浪费资源
        ② client有个新的应用程序刚好分配了同一个端口号，新的应用程序收到FIN后马上开始执行断开连接的操作，本来它可能是想跟server建立连接的

TCP —— 释放连接 —— 疑问

为什么释放连接的时候，要进行4次挥手？（两次不行吗？？，前两次挥手仅仅代表关闭了主机1给主机2发信息的通道，但是主机2依然可以发数据给主机1）
TCP是全双工模式（我发东西给你的同时，你也可以发东西给我）

• 第1次挥手：当主机1发出FIN报文段时（仅仅代表主机1不会发东西给主机2了）

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

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

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

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

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

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

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

TCP —— 释放连接 —— 抓包

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

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

当server接收到client的FIN时，如果server后面也没有数据要发送给client了
这时， server就可以将第2、 3次挥手合并，同时告诉client两件事

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

一个问题：我们常常提到的长连接和短连接是如何区分的？

创建完连接后，发完一轮数据（做完一轮交互），立马就关了（断开连接）—— 短连接 

所以如何区分长连接和短连接：拿完数据是否立马断开连接