运输层协议简析

目录
TCP报文分析
UDP报文分析
总结

TCP报文分析

浏览器访问FTP服务器（同时是web网站），抓包分析TCP协议：

三次握手建立连接：

本地主机发送连接请求——

源端口：62449；
目的端口：21，ftp协议默认端口；
字节流索引号：4。“流索引”显示每个流的唯一编号。流是TCP数据包的相关集合，通常从三次握手开始，然后是数据传输，最后是会话断开。从会话开始到结束的所有数据包的流索引都是一样的，即流索引标识着一次完整的会话；
TCP Segment Len：这里TCP分组长度为0；
序号：0，该报文不能携带数据，但要消耗一个序号；
确认号：0，期待收到对方下一个报文段的第一个数据字节的序号；
数据偏移：10，单位为4个字节，即40字节，它也表示TCP报文首部的长度；

Flags:

1. Reserved保留字段：not set
2. URG、ACK、PSH、RST、FIN均置0
3. URG=1告诉TCP本报文中有紧急数据，要将紧急数据放在数据部分的最前面；
4. ACK=1时确认号字段才有效，TCP规定，建立连接后的所有传送的报文段都必须把ACK置1；
5. PSH：接收方在接收到PSH=1的报文时，就尽快地交付接收应用进程，而不再等待整个缓存都填满了才向上交付；
6. RST：RST=1表示TCP连接出错，强制释放连接，然后重连，还可以用来拒绝一个非法报文或拒绝打开一个连接；
7. FIN：用来释放一个连接，FIN=1时，表示此报文段的发送方的数据已经发送完毕，并要求释放运输连接；
8. SYN=1，该控制位用于在建立连接时同步序号，SYN置1而ACK为0，表示这是一个连接请求，如果ACK和SYN都等于1，则表示这是一个连接响应报文。（序号为1的报文出现在连接阶段，ACK为0为请求方发送，ACK为1为响应方发送）；
   窗口大小：64240字节，表示FTP服务器可以发送的数据量不能超过64240个字节；
   校验和：0xfc49,检验和字段检验的范围包括首部和数据这两部分；
   紧急指针：只在控制为URG为1的时候有效，用来标记紧急数据的末尾位置；
   

选项：

1. 最大报文长度（MSS）：1460bytes，表示发送方支持的TCP报文段中的数据字段的最大长度，常用的以太网最大传送单元MTU为1500bytes，因为该报文的TCP首部为40字节，所以MSS=1460bytes，MSS的默认值为536字节；

2. NOP表示无操作；

3. Window scale：窗口扩大选项，占3个字节，这里的8表示移位值，即窗口位数可扩大8位，（16+8）；

4. SACK permitted：选择确认选项，通过汇报不连续的字节块的边界实现发送方只传送缺少的数据而不重传已经正确到达接收方的数据；

5. 时间戳：占10字节，时间戳值字段占4个字节，有两个用途，一是计算往返时间RTT，时间戳值记录的是分组发出是的时间，而是用于处理TCP序号超过232的情况，及防止序号绕回PAWS，相同序号的分组可根据时间戳值之差的大小区分新旧报文；
   

FTP服务器返回响应——

流索引和请求分组的一样，都是4；
序号为0，这是FTP服务器发送给本主机的第一个TCP报文，不能携带数据，但要消耗一个序号，所以序号为0；
确认号为1，FTP服务器期望收到下一个报文段的第一个数据字节的序号为1，若确认号 = N ，则表明，到序号N-1为止的所有数据都已正确收到；

控制位:
建立连接后ACK确认控制位置1；
SYN同步序号，置1；

窗口大小：28960字节
选项字段：

MSS与本主机所支持的有所差异。

RTT的计算结果为0.014784000s

本主机应答——

序号和确认号变化了，

只有控制位确认Ack置1；
这次的窗口大小为512，再加上之前的窗口扩大选项值8，实际支持对方传输的数据量为131072，正好2（9+8）大小。
至此，三次握手结束，主机与FTP服务器的连接建立。

在封装数据为FTP数据报时，PUSH控制位始终置1

TCP四次挥手断开连接

FTP服务器发起释放连接，控制位FIN置1，确认位置1

该报文的序号为649，确认号ack=774，等于本主机上一次发送的报文序号773+1，因为上一次主机发送的数据仅有一个字节，

此时FTP服务器处于FIN-WAIT-1（终止等待1），注释放连接报文即使不携带数据也要消耗一个序号。
主机接收到FTP服务器的释放连接报文，便发出确认，发送一个ACK报文，序号为774（本主机上一个发送的报文中只有一字节数据，所以774=773+1），确认号ack=650=释放连接报文序号649+1（释放连接报文并未携带数据，所以+1），该报文控制位只有确认位置1。
此时本主机处于CLOSED-WAIT（关闭等待）状态，此时TCP连接处于半关闭状态，FTP服务器不会再发送任何数据，但能接收来自本主机的数据，只等待本主机的释放连接，这次会话就结束。
本地主机没有数据要继续传输，相关应用进程便通知TCP释放连接，发送一个释放连接报文：

本主机发送的释放连接报文序号为774；

控制位上确认位和终止位均置1。
当FTP提出释放连接而本主机没有数据要发送时，这两个报文可以合并成一个报文发送。
FTP服务器返回确认报文，本主机收到后断开连接，服务器在等待2MSL时间后也断开连接，MSL叫做最长报文段寿命，任何报文在网络上存在的最长时间，超时将被丢弃，服务器等待2MSL是为了防止本主机没有接收到ACK报文，并且可以有足够时间接收主机的新的释放连接请求（重发）。
RST复位报文：

RST复位报文的上一个报文，期望的序号为101：

RST报文，窗口大小设为0，表示不接受任何数据。

UDP报文分析

命令行输入nslookup baidu.com，抓包

源端口：56471，占两字节
目的端口：53（DNS服务默认端口），占两字节
长度：46，UDP用户数据报长度，最小为8（仅有首部），占两字节
校验和：检测UDP用户数据报在传输中是否有错，有错则丢弃。
上层的DNS报文作为数据被封装在了UDP用户数据报文的数据部分
UDP首部8字节加上DNS报文内容的38字节，刚好等于UDP长度46字节：

总结

1. 序号为0表示连接建立阶段，这时候第一、二次握手的报文都不能携带数据，但都要消耗一个序号。Wireshark显示的序号有两种，一种是相对序号，相对于本次会话，从0开始，另一种是实际序号。

2. 无条件消耗序号的情况：
   a) 建立连接的第一、二次握手，发送的释放连接报文不能携带数据，但都会消耗一个序号
   b) TCP规定，FIN报文即使不携带数据，也要消耗一个序号

3. 介绍三次握手：
   a) 指TCP连接建立时通信双方一共要发送三个报文
   b) 作用：
   i. 确认彼此的接收和发送能力是否正常
   ii. 交换滑动窗口大小信息
   iii. 交换MSS--最大报文段长度
   iv. 同步连接双方的序列号和确认号等等

4. 介绍四次挥手：
   a) 指TCP连接双方在结束会话时一共要发送四个报文
   b) 连接终止是双方面的，发送了FIN报文的一端就不在传输数据，但可以继续接受数据，当双方都发送了FIN报文后，连接才算终止。
   c) 之所以要四次挥手，是因为在发送对对方FIN报文的确认之后，本主机可能还有数据要发送，而不是立刻就终止。

5. 关于滑动窗口：
   滑动窗口大小是可变的，实际窗口大小=窗口字段值*窗口扩展

6. 底层协议封装上层协议数据单元是直接将其作为数据部分进行下传或传输。

感谢阅读！