TCP报文头部

TCP包头详解

主要学习端口号、三次握手、四次挥手

TCP包头

• TCP报文固定长度20字节+可变长度

• TCP包头如下图所示：
  

• 源端口、目标端口：计算机上的进程要和其他进程通信是要通过计算机端口的，而一个计算机端口某个时刻只能被一个进程占用，所以通过指定源端口和目标端口，就可以知道是哪两个进程需要通信。源端口、目标端口是用16位表示的，可推算计算机的端口个数为2^16个

• 序列号：表示本报文段所发送数据的第一个字节的编号。在TCP连接中所传送的字节流的每一个字节都会按顺序编号。由于序列号由32位表示，所以每2^32个字节，就会出现序列号回绕，再次从 0 开始

• 确认号：表示接收方期望收到发送方下一个报文段的第一个字节数据的编号。也就是告诉发送方：我希望你（指发送方）下次发送的数据的第一个字节数据的编号为此确认号

• 数据偏移：表示TCP报文段的首部长度，共4位，由于TCP首部包含一个长度可变的选项部分，需要指定这个TCP报文段到底有多长。它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。该字段的单位是32位(即4个字节为计算单位），4位二进制最大表示15，所以数据偏移也就是TCP首部最大60字节

• URG：表示本报文段中发送的数据是否包含紧急数据。后面的紧急指针字段（urgent pointer）只有当URG=1时才有效

• ACK：表示是否前面确认号字段是否有效。只有当ACK=1时，前面的确认号字段才有效。TCP规定，连接建立后，ACK必须为1,带ACK标志的TCP报文段称为确认报文段

• PSH：提示接收端应用程序应该立即从TCP接收缓冲区中读走数据，为接收后续数据腾出空间。如果为1，则表示对方应当立即把数据提交给上层应用，而不是缓存起来，如果应用程序不将接收到的数据读走，就会一直停留在TCP接收缓冲区中

• RST：如果收到一个RST=1的报文，说明与主机的连接出现了严重错误（如主机崩溃），必须释放连接，然后再重新建立连接。或者说明上次发送给主机的数据有问题，主机拒绝响应，带RST标志的TCP报文段称为复位报文段

• SYN：在建立连接时使用，用来同步序号。当SYN=1，ACK=0时，表示这是一个请求建立连接的报文段；当SYN=1，ACK=1时，表示对方同意建立连接。SYN=1，说明这是一个请求
  建立连接或同意建立连接的报文。只有在前两次握手中SYN才置为1，带SYN标志的TCP报文段称为同步报文段

• FIN：表示通知对方本端要关闭连接了，标记数据是否发送完毕。如果FIN=1，即告诉对方：“我的数据已经发送完毕，你可以释放连接了”，带FIN标志的TCP报文段称为结束报文段

• 窗口大小：表示现在允许对方发送的数据量，也就是告诉对方，从本报文段的确认号开始允许对方发送的数据量，达到此值，需要ACK确认后才能再继续传送后面数据，由Window size value * Window size scaling factor（此值在三次握手阶段TCP选项Window scale协商得到）得出此值

• 校验和：提供额外的可靠性

• 紧急指针：标记紧急数据在数据字段中的位置

• 选项部分：其最大长度可根据TCP首部长度进行推算。TCP首部长度用4位表示，选项部分最长为：(2^4-1)*4-20=40字节
  常见选项：
     最大报文段长度：Maxium Segment Size，MSS，通常1460字节
     窗口扩大：Window Scale
     时间戳： Timestamps

• 1 最大报文段长度MSS（Maximum Segment Size）
  指明自己期望对方发送TCP报文段时那个数据字段的长度。比如：1460字节。数据字段的长度加上TCP首部的长度才等于整个TCP报文段的长度。MSS不宜设的太大也不宜设的太小。若选择太小，极端情况下，TCP报文段只含有1字节数据，在IP层传输的数据报的开销至少有40字节（包括TCP报文段的首部和IP数据报的首部）。这样，网络的利用率就不会超过1/41。若TCP报文段非常长，那么在IP层传输时就有可能要分解成多个短数据报片。在终点要把收到的各个短数据报片装配成原来的TCP报文段。当传输出错时还要进行重传，这些也都会使开销增大。因此MSS应尽可能大，只要在IP层传输时不需要再分片就行。在连接建立过程中，双方都把自己能够支持的MSS写入这一字段。 MSS只出现在SYN报文中。即：MSS出现在SYN=1的报文段中
  MTU和MSS值的关系：MTU=MSS+IP Header+TCP Header
  通信双方最终的MSS值=较小MTU-IP Header-TCP Header

• 2 窗口扩大
  为了扩大窗口，由于TCP首部的窗口大小字段长度是16位，所以其表示的最大数是65535。但是随着时延和带宽比较大的通信产生（如卫星通信），需要更大的窗口来满足性能和吞吐率，所以产生了这个窗口扩大选项

• 3 时间戳
  可以用来计算RTT(往返时间)，发送方发送TCP报文时，把当前的时间值放入时间
  戳字段，接收方收到后发送确认报文时，把这个时间戳字段的值复制到确认报文中，当发送方收到确认报文后即可计算出RTT。也可以用来防止回绕序号PAWS，也可以说可以用来区分相同序列号的不同报文。因为序列号用32为表示，每2^32个序列号就会产生回绕，那么使用时间戳字段就很容易区分相同序列号的不同报文

源端口和目标端口

• 下层协议是为上层提供服务的，因此在传输层为了区分上层应用程序使用源端口和目标端口的方式区分应用程序不同的应用程序。

• 端口号是用来区分同一台主机上的不同程序的，不同程序的唯一标准。

• 端口号总共16位 --> 2^16=65535,意味着一台主机最多只能运行65535个与网络相关的应用程序。有些情况下一个应用程序会占用对个端口，一般也达不到这个应用程序，因此端口数足够使用。

• 请求报文：
  目标端口 ==> 服务器，约定俗成
  源端口 ===> 客户端，随机分配

• 响应报文：
  源端口 ==> 服务器，约定俗成
  目标端口 ===> 客户端，随机分配

• 连接会话的区别：
  eg：
  ①使用xshell连接VMware中的Linux时，当xshell连接时选择ssh复制生成的终端属于会话。会话属于同一链路，会话不会分配端口。
  ②使用xshell再建立一个连接属于连接：连接会创建一条新的链路，重新分配端口。
  连接可以利用ss -tn查看

[root@centos7 ~]# ss -tn
State  Recv-Q Send-Q  Local Address:Port  Peer Address:Port              
ESTAB  0      0       192.168.38.7:22      192.168.38.1:7915               
ESTAB  0      52      192.168.38.7:22      192.168.38.1:1321
1
2
3
4

• 常见服务与其对应的端口
  
  tcp
  http 80
  https 443
  ssh 22
  telnet 23
  ftp 21
  smtp 25
  pop 110
  imap 143
  mysql 3306
  oracle 1521
  sql server 1433 1434

查询端口：（有时开发的服务需要对外提供服务，此时需要查询确认端口未被占用，
此时可以查询哪些端口被占用）
~]vim /etc/services （/etc/services 记录了一些著名服务使用的协议和端口号）
1
2
3

• TCP协议PORT
  1）传输层通过port号，确定应用层协议
  2）Port number:
  3）tcp：传输控制协议，面向连接的协议；通信前需要建立虚拟链路；结束后拆除链路
     0-65535
  4）udp：User Datagram Protocol，无连接的协议
     0-65535
  5）IANA:互联网数字分配机构（负责域名，数字资源，协议分配）
     0-1023：系统端口或特权端口(仅管理员可用) ，众所周知，永久的分配给固定的系统应用使用，22/tcp(ssh), 80/tcp(http), 443/tcp(https)
     1024-49151：用户端口或注册端口，但要求并不严格，分配给程序注册为某应用使用，1433/tcp(SqlServer), 1521/tcp(oracle),3306/tcp(mysql)11211/tcp/udp (memcached)
     49152-65535：动态端口或私有端口，客户端程序随机使用的端口
  其范围的定义：/proc/sys/net/ipv4/ip_local_port_range==》特定场合需要改此值；一般反向代理时此值需要改大（1024 65535）

-l 是显示处于监听的端口；相当于默认开了哪些软件；
    [root@centos7 ~]# ss -tnl
    State   Recv-Q Send-Q   Local Address:Port   Peer Address:Port              
    LISTEN  0      128      *:111                *:*                  
    LISTEN  0      128      *:6000               *:*                  
    LISTEN  0      128      *:47220              *:*                  
    LISTEN  0      5        192.168.122.1:53     *:*                  
    LISTEN  0      128      *:22                 *:*                  
    LISTEN  0      128      127.0.0.1:631        *:*   
    .....

当然面试时也经常会问哪个端口哪个程序正在使用：
    ①ss -tnlp （p选项）
    ②lsof -i :22（查询22端口哪个软件被占用）
1
2
3
4
5
6
7
8
9
10
11
12
13
14

序号

• 当数据报文比较大时，会涉及切包（因为在数据链路层帧结构中数据的最大是1500字节），在切包以后，每个包都有一个编号。

• 序号的作用之一：当接收方接收到数据时，可以根据序号进行组合

• 序号的作用之二：传输时，丢包有序号，以便减少重传的包的数量

• 如何验证丢包？—>确认号

确认号

• 确认号是通信双方：接收方需要确认收到的数据包

• 如何确认？
  ①eg：发送第 # 个包时，回复确认号为 #
  ②eg：发送第 # 个包时，回复确认号为 #+1，希望你下次发送下一个包

• 网络中通信利用的是②这种机制

• 报文包的个数总共32位有2^32个报文编号

• 仅靠编号不能区分报文时，加时间戳

• 接收方回应发送方：举例：

确认号：ack < ==== > 序列号：seq （从上往下分析）
① client向server 请求：
seq 10：表示 client 目前发送第10个包给 server
ack 1： 表示 client 收到了 server 刚给它发的第0个包

②server向client 响应：
seq 1： server 应 client 要求，将 1 包发送给 client
ask 11：server 告诉 client ，client 刚给它的 10 包已收到

③…以此类推
这种逻辑是每次都会收发确认，无形中效率不高…提高效率的方式：阶段性的回答收到还是未收到—>涉及窗口的问题

窗口

固定窗口

• 窗口则是发多少个包确认一次

• 若Window size=1，则表示一个包确认一次：
  

• 窗口Window size=3 三个包确认一次
  
  这种窗口固定的逻辑逻辑也不是特别好，窗口固定，但是网络并不是稳定不变的

滑动窗口

• 工作中常用滑动窗口
  
  发送方< ==== >接收方
  原理：刚开始发送方会假设接收方一次能接受 # 个数据包，接受方回应发送方能收具体的数据包（若全收，发送方将增大#值，再试）此时相当于双方协商。当然发送过程根据不然的网络状态还会进行实时调整，因此TCP可以进行流量控制。

• 目前在tcp包头中，窗口总共16位，则一次性的的报文最大为2^16=65536，但是随着网络带宽的增加，还是显得有点小。

• 引入Window size scaling factor 以便扩大窗口大小。

• 窗口扩大因子（Window size scaling factor ）此值是在通信双方第一次通信时协商出来的，因子大小是固定的，但是窗口大小是变化的

• 通信双方可能各有各自的因子，传输时=自己的因子大小*每次发送的窗口大小

数据偏移

• 数据报文的头部有多长，TCP报文头部大小并不固定，其中部分内容是可选的。

• TCP报文头部的固定内容：每一行32bit（4字节）* 5行 =20字节
  

• 可变部分：
  

保留

• 保留 - 保留了一部分数据位，空着的，目前未使用

校验和

• 校验数据是否被破坏

紧急指针

选项部分

• 常见选项

• 最大报文段长度：Maxium Segment Size，MSS，通常1460字节
     此最大报文长度是根据帧的数据位最大为1500，帧的数据位包括了网络层的头部和传输层的头部（各20字节固定长度）

• 窗口扩大：Window Scale

• 时间戳： Timestamps

六个特殊标志

• 在保留位之后是六个特殊标记，这六个标记分别的作用为：

• URG： 表示紧急指针（urgent pointer）中内容是否有效：表示的是固定长度的最后一个紧急指针（16bit），如果此处URG=1，则紧急指针有效，URG=0则紧急指针的内容无效

• RST：reset：若RST=1则表示与主机的连接出现了严重故障，需要重新建立连接；RST标志的TCP报文段称为复位报文段

• PSH：表示网卡收到应用程序发过来的数据以后，默认情况将放置在内核中TCP缓冲区中，等待一段时间再将数据复制至应用程序。若PSH=1则表示立即将数据传给应用程序不再缓存；若PSH=0则表示默认情况

• 重点掌握以下三个特殊标志：

• ACK、SYN、FIN与建立TCP的通信息息相关，主机利用TCP协议进行通信之前需要建立TCP连接，建立连接的作用：确保通信双方可以进行安全可靠的通信。

三次握手

• 建立连接的过程一般被称为TCP的三次握手：
  
  三次握手的实现：如上图所示
  通常未进行通信过的两个主机，第一次发起请求的一般为客户端
  seq为序号 ack为确认号 大写ACK SYN FIN为三个特殊标记
     ①第一次发起请求时：client 设置 SYN=1 seq=x
    
     抓包软件可看到tcp请求连接建立的标志位SYN=1
     ② server收到时立即回应：server 回应 SYN=1 ACK=1 seq=y ack=x+1
     ③ client收到是立即回应：client 回应 ACK=1 seq=x+1 ack=y+1
     ④以上①②③ TCP三次握手就成功啦，建立连接，进行数据通信

• 在TCP三次握手时，两个主机的网络连接状态是有变化的：
     ①server端必须事先将能够接受client服务的端口处于LISTEN状态。
     ②在访问server之前，client的随机端口也未被打开，当client去访问server时，随机端口打开，发起TCP建立连接请求，此时client的网络状态自动变为SYN-SENT状态。
     ③server端收到client端的连接建立请求后，server的网络状态由listen – > SYN-RCVD。
     ④client发送连接确认后，client的网络状态由 SYN-SENT --> ESTAB-LISHED。
     ⑤ server 再次收到连接确认时，server的网络状态有SYN-RCVD --> ESTAB-LISHED。
     server : LISTEN --> SYN-RCVD --> ESTAB-LISHED
     client : SYN-SENT --> ESTAB-LISHED

四次挥手

• TCP的四次挥手

• 断开连接请求：可以是client 也可以是server
  
  图中当server端收到client的断开请求时，可能涉及到传输的数据没有传完，因此server端不会立即同意断开请求，可以继续给client端发送数据。此阶段数据传输是单向的（半双工，半关闭）
  当server端同意断开请求连接时，client的网络状态并未立即切换，因为先发的报文并不一定比server同意断开请求先到，需要等待2MSL（报文最长存活时间）时间，确认server端的数据全部接收后，才会改变网络状态。

有限状态机FSM：Finite State Machine

• CLOSED 没有任何连接状态

• LISTEN 侦听状态，等待来自远方TCP端口的连接请求

• SYN-SENT 在发送连接请求后，等待对方确认

• SYN-RECEIVED 在收到和发送一个连接请求后，等待对方确认

• ESTABLISHED 代表传输连接建立，双方进入数据传送状态

• FIN-WAIT-1 主动关闭,主机已发送关闭连接请求，等待对方确认

• FIN-WAIT-2 主动关闭,主机已收到对方关闭传输连接确认，等待对方发送关闭传输连接请求

• TIME-WAIT 完成双向传输连接关闭，等待所有分组消失

• CLOSE-WAIT 被动关闭,收到对方发来的关闭连接请求，并已确认

• LAST-ACK 被动关闭,等待最后一个关闭传输连接确认，并等待所有分组消失

• CLOSING 双方同时尝试关闭传输连接，等待对方确认

有限状态机

• 客户端先发送一个FIN给服务端，自己进入了FIN_WAIT_1状态，这时等待接收
  服务端的报文，该报文会有三种可能：
  ①只有服务端的ACK
  ②只有服务端的FIN
  ③基于服务端的ACK，又有FIN
• 1、只收到服务器的ACK，客户端会进入FIN_WAIT_2状态，后续当收到服务端的FIN时，回应发送一个ACK，会进入到TIME_WAIT状态，这个状态会持续2MSL(TCP报文段在网络中的最大生存时间, RFC 1122标准的建议值是2min).客户端等待2MSL，是为了当最后一个ACK丢失时，可以再发送一次。因为服务端在等待超时后会再发送一个FIN给客户端，进而客户端知道ACK已丢失
• 2、只有服务端的FIN时，回应一个ACK给服务端，进入CLOSING状态，然后接收到服务端的ACK时，进入TIME_WAIT状态
• 3、同时收到服务端的ACK和FIN，直接进入TIME_WAIT状态

客户端的典型状态转移

• 客户端通过connect系统调用主动与服务器建立连接connect系统调用首先给服务器发送一个同步报文段，使连接转移到SYN_SENT状态

• 此后connect系统调用可能因为如下两个原因失败返回：

• 1、如果connect连接的目标端口不存在（未被任何进程监听），或者该端口仍被处于TIME_WAIT状态的连接所占用（见后文），则服务器将给客户端发送一个复位报文段，connect调用失败。

• 2、如果目标端口存在，但connect在超时时间内未收到服务器的确认报文段，则connect调用失败。

• connect调用失败将使连接立即返回到初始的CLOSED状态。如果客户端成功收到服务器的同步报文段和确认，则connect调用成功返回，连接转移至ESTABLISHED状态

• 当客户端执行主动关闭时，它将向服务器发送一个结束报文段，同时连接进入FIN_WAIT_1状态。若此时客户端收到服务器专门用于确认目的的确认报文段，则连接转移至FIN_WAIT_2状态。当客户端处于FIN_WAIT_2状态时，服务器处于CLOSE_WAIT状态，这一对状态是可能发生半关闭的状态。此时如果服务器也关闭连接（发送结束报文段），则客户端将给予确认并进入TIME_WAIT状态

• 客户端从FIN_WAIT_1状态可能直接进入TIME_WAIT状态（不经过FIN_WAIT_2状态），前提是处于FIN_WAIT_1状态的服务器直接收到带确认信息的结束报文段（而不是先收到确认报文段，再收到结束报文段）

• 处于FIN_WAIT_2状态的客户端需要等待服务器发送结束报文段，才能转移至TIME_WAIT状态，否则它将一直停留在这个状态。如果不是为了在半关闭状态下继续接收数据，连接长时间地停留在FIN_WAIT_2状态并无益处。连接停留在FIN_WAIT_2状态的情况可能发生在：客户端执行半关闭后，未等服务器关闭连
  接就强行退出了。此时客户端连接由内核来接管，可称之为孤儿连接（和孤儿
  进程类似）

• Linux为了防止孤儿连接长时间存留在内核中，定义了两个内核参数：
  /proc/sys/net/ipv4/tcp_max_orphans 指定内核能接管的孤儿连接数目
  /proc/sys/net/ipv4/tcp_fin_timeout 指定孤儿连接在内核中生存的时间