网络互连模型 (运输层)

传输层有2个协议:
    TCP (Transmission Control Protocol), 传输控制协议
    UDP (User Datagram Protocol), 用户数据报协议

 

UDP(用户数据报协议)

数据格式

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

UDP长度(Length): 占16位, 首部的长度 + 数据的长度

 

检验和

检验和的计算内容: 伪首部 + 首部 + 数据
伪首部: 仅在计算检验和时起作用, 并不会传递给网络层 (在接收端校验检验和时, 也会加入伪首部)

端口

UDP首部中端口是占用2字节, 可以推测出端口号的取值范围是：0~65535
客户端的源端口是临时开启的随机端口
防火墙可以设置开启\关闭某些端口来提高安全性

常用命令行:

• netstat –an: 查看被占用的端口
• netstat –anb: 查看被占用的端口、占用端口的应用程序
• telnet 主机 端口: 查看是否可以访问主机的某个端口 (安装telnet: 控制面板 – 程序 – 启用或关闭Windows功能 – 勾选“Telnet Client” – 确定)

---

TCP(传输控制协议)

数据格式

数据偏移

• 占4位, 取值范围是0x0101~0x1111
• 乘以4: 首部长度(Header Length)
• 首部长度是20~60字节

保留

• 占6位, 目前全为0

注意点1:

在有些资料中, TCP首部的保留(Res)字段占3位, 标志(Flags)字段占9位;  (由于标志(Flags)字段的前3个位并没有使用, 所以也可以说保留位为6位)

注意点2:

 UDP的首部中有个16位的字段记录了整个UDP报文段的长度(首部+数据); 但是, TCP的首部中仅仅有个4位的字段记录了TCP报文段的首部长度, 并没有字段记录TCP报文段的数据长度
分析:
UDP首部中占16位的长度字段是冗余的, 纯粹是为了保证首部是32bit对齐
TCP\UDP的数据长度, 完全可以由IP数据包的首部推测出来
传输层的数据长度 = 网络层的总长度 – 网络层的首部长度 – 传输层的首部长度

检验和 (Checksum)

和UDP一样, TCP检验和的计算内容: 伪首部 + 首部 + 数据
伪首部: 占用12字节, 仅在计算检验和时起作用, 并不会传递给网络层 (接收端校验检验和时也会加入伪首部)

标志位 (Flags)

URG(Urgent): 当URG=1时，紧急指针字段才有效。表明当前报文段中有紧急数据，应优先尽快传送
ACK(Acknowledgment): 当ACK=1时，确认号字段才有效
PSH(Push): 提示接收端应用程序立即从TCP缓冲区把数据读走
RST(Reset): 当RST=1时，表明连接中出现严重差错，必须释放连接，然后再重新建立连接
SYN(Synchronization): 当SYN=1、ACK=0时, 表明这是一个建立连接的请求; 若对方同意建立连接, 则回复SYN=1、ACK=1
FIN(Finish):  当FIN=1时, 表明数据已经发送完毕, 要求释放连接

序号 (Sequence Number)

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

确认号 (Acknowledgment Number)

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

窗口 (Window)

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

 

TCP - 可靠传输

停止等待ARQ协议

ARQ (Automatic Repeat–reQuest), 自动重传请求

问题: 若有个包重传了N次还是失败,会一直持续重传到成功为止么？

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

连续ARQ协议 + 滑动窗口协议

如果接收窗口最多能接收4个包,但发送方只发了2个包, 接收方如何确定后面还有没有2个包？
接收方等待一定时间后没有第3个包, 就会返回确认收到2个包给发送方

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

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

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

SACK (选择性确认)

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

问题: 为什么选择在传输层就将数据分成多个段，而不是等到网络层再分片传递给数据链路层 ？
因为可以提高重传的性能
       需要明确的是：可靠传输是在传输层进行控制的
       如果在传输层不分段, 一旦出现数据丢失, 整个传输层的数据都得重传
       如果在传输层分了段, 一旦出现数据丢失, 只需要重传丢失的那些段即可

TCP - 流量控制

如果接收方的缓存区满了, 发送方还在疯狂着发送数据
接收方只能把收到的数据包丢掉, 大量的丢包会极大着浪费网络资源, 所以要进行流量控制

什么是流量控制？
让发送方的发送速率不要太快, 让接收方来得及接收处理

原理:

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

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

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

TCP - 拥塞控制

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

MSS (Maximum Segment Size): 每个段最大的数据部分大小(在建立连接时确定)
cwnd (congestion window): 拥塞窗口
rwnd (receive window): 接收窗口
swnd (send window): 发送窗口, swnd = min(cwnd, rwnd)

 

拥塞控制 - 慢开始

接收窗口(cwnd)的初始值比较小, 然后随着数据包被接收方确认(收到一个ACK), cwnd就成倍增长(指数级)

 

拥塞控制 - 拥塞避免

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

 

拥塞控制 - 快重传

接收方: 每收到一个失序的分组后就立即发出重复确认, 使发送方及时知道有分组没有到达, 而不要等待自己发送数据时才进行确认
发送方: 只要连续收到三个重复确认（总共4个相同的确认），就应当立即重传对方尚未收到的报文段, 而不必继续等待重传计时器到期后再重传

拥塞控制 - 快恢复

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

 

快重传 + 快恢复

发送窗口的最大值:  swnd = min(cwnd, rwnd)

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

---

TCP - 连接管理

序列号、确认号

1. 连接过程图示:

2. 连接过程中序列号、确认号分析:

3. 连接过程中序列号、确认号分析总结

建立连接

     

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

case LISTEN状态:
     if(收到"发送数据"报文){
	    发送SYN报文段
		进入SYN-SENT状态
	 }
	 if(收到任何SYN报文段){
	    发送SYN+ACK报文段
		进入SYN-RCVD状态
	 }
	 if(收到任何其他报文段或者报文){
	    发出差错报文
	 }
	 break
	 
case SYN-SENT状态:
     if(超时){
	    进入CLOSED状态
	 }
	 if(收到SYN报文段){
	    发送SYN+ACK报文段
		进入SYN-RCVD状态
	 }
	 if(收到SYN+ACK报文段){
	    发送ACK报文段
		进入ESTABLISHED状态
	 }
	 if(收到任何其他报文段或者报文){
	    发出差错报文
	 }
	 break

case SYN-RCVD状态:
     if(收到ACK报文段){
	    进入ESTABLISHED状态
	 }
	 if(超时){
	    发送RTS报文段
		进入CLOSED状态
	 }
	 if(收到"关闭"报文){
	    发送FIN报文段
		进入FIN-WAIT-1状态
	 }
	 if(收到RTS报文段){
	    进入LISTEN状态
	 }
	 if(收到任何其他报文段或者报文){
	    发出差错报文
	 }
	 break
	 
case ESTABLISHED状态:
     if(收到FIN报文段){
	    发送FIN报文段
		进入CLOSED-WAIT状态
	 }
     if(收到"关闭"报文){
	    发送FIN报文段
		进入FIN-WAIT-1状态
	 }
     if(收到RTS或SYN报文段){
	    发出差错报文
	 }
	 if(收到数据或ACK报文段){
	    调用输入模块
	 }
     if(收到"发送"报文){
	    调用输出模块
	 }
     break

 

Wireshark抓包:

前两次握手的特点:
    1. SYN都设置为1
    2. 数据部分的长度都为0
    3. TCP头部的长度一般是32字节
           固定头部: 20字节
           选项部分: 12字节
    4. 双方会交换确认一些信息
           比如MSS、是否支持SACK、Window scale(窗口缩放系数)等
           这些数据都放在了TCP头部的选项部分中(12字节)

建立连接 - 疑问1

为什么建立连接的时候，要进行3次握手？2次不行么？
主要目的：防止server端一直等待，浪费资源

如果建立连接只需要2次握手，可能会出现的情况:
        假设client发出的第一个连接请求报文段，因为网络延迟，在连接释放以后的某个时间才到达server; 本来这是一个早已失效的连接请求，但server收到此失效的请求后，误认为是client再次发出的一个新的连接请求;于是server就向client发出确认报文段，同意建立连接; 如果不采用“3次握手”，那么只要server发出确认，新的连接就建立了; 由于现在client并没有真正想连接服务器的意愿，因此不会理睬server的确认，也不会向server发送数据; 但server却以为新的连接已经建立，并一直等待client发来数据，这样，server的很多资源就白白浪费掉了

采用“三次握手”的办法可以防止上述现象发生
       例如上述情况，client没有向server的确认发出确认，server由于收不到确认，就知道client并没有要求建立连接

建立连接 - 疑问2

第3次握手失败了，会怎么处理？
       此时server的状态为SYN-RCVD，若等不到client的ACK，server会重新发送SYN+ACK包; 如果server多次重发SYN+ACK都等不到client的ACK，就会发送RST包，强制关闭连接

建立连接 - 疑问3

当三次握手后, 客户端与服务端都进入establish状态(连接已经建立), 那么连接已经建立对于客户端与服务端来说到底是什么?
      在连接建立后, 代表客户端与服务端都进入就绪状态, 可以进行数据传输; 以java应用为例:在客户端中创建了Socket对象, 并绑定监听了对应端口;在服务端中通过ServerSocket创建了对应客户端的Socket实例, 准备进行数据交互

---

释放连接

 

case FIN-WAIT-1状态:
     if(收到FIN报文段){
	    发送ACk报文段
		进入CLOSING状态
	 }
	 if(收到FIN+ACK报文段){
	    发送ACk报文段
		进入FIN-WAIT状态
	}
	 if(收到ACK报文段){
	    进入FIN-WAIT-2状态
	}
	if(收到任何其他报文段或者报文){
	    发出差错报文
	break
	
case CLOSED-WAIT状态
    if(收到"关闭"报文){
	   发送FIN报文段
	   进入LAST-ACK状态
	}
	if(收到任何其他报文段或者报文){
	   发出差错报文
	}
	break 

case FIN-WAIT-2状态
    if(收到FIN报文段){
	   发送ACK报文段
	   进入TIME-WAIT状态
	}
	break 	

case CLOSING状态
    if(收到ACK报文){
	   进入TIME-WAIT状态
	}
	if(收到任何其他报文段或者报文){
	   发出差错报文
	}
	break 
	
case LAST-ACK状态
    if(收到ACK报文段){
	   进入CLOSED状态
	}
	if(收到任何其他报文段或者报文){
	   发出差错报文
	}
	break 
	
case TIME-WAIT状态
    if(超时){
	   进入CLOSED状态
	}
	if(收到任何其他报文段或者报文){
	   发出差错报文
	}
	break 
	
case CLOSED状态
    if(收到"被动打开"报文){
	   进入LISITEN状态
	}
	if(收到"主动打开"报文){
	   发送SYN报文段
	   进入SYN-SENT状态
	}
	if(收到任何报文段){
	   发送RST报文段
	}
	if(收到任何其他报文){
	   发出差错报文
	}
	break 

Wireshark抓包分析(Client端口:55738, Server端口:8888)

释放连接 - 状态解读
    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状态, 表示双方都正在关闭SOCKET连接
    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等

释放连接 - 细节
TCP/IP协议栈在设计上，允许任何一方先发起断开请求。这里演示的是client主动要求断开
Client发送ACK后，需要有个TIME-WAIT阶段，等待一段时间后，再真正关闭连接, 一般是等待2倍的MSL(Maximum Segment Lifetime，最大分段生存期), 2MSL就是一个发送和一个回复所需的最大时间; 如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。
    ① MSL是TCP报文在Internet上的最长生存时间
    ② 每个具体的TCP实现都必须选择一个确定的MSL值，RFC 1122建议是2分钟
如果Client发送ACK后马上释放了(不等待2MSL时长)，然后又因为网络原因，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次' 挥手场景

有时候在使用抓包工具的时候，有可能只会看到 '3次' 挥手, 这其实是将第2、3次挥手合并了

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

---

连接管理完整流程