TCP报文的头部结构

叁歲伎倆 2024-03-17 10:38 48阅读 0赞

**TCP****报文的头部结构**

ACK：确认序号有效。

FIN：释放一个连接。

PSH：接收方应该尽快将这个报文交给应用层。

RST：重置连接。

SYN：发起一个新连接。

URG：紧急指针（urgent pointer）有效。

不要将确认序号ack与标志位中的ACK搞混了。

确认方ack=发起方seq+1，两端配对。

**三次握手**

第一次握手：客户端要向服务端发起连接请求，首先客户端随机生成一个起始序列号ISN(比如是100)，那客户端向服务端发送的报文段包含SYN标志位(也就是SYN=1)，序列

号seq=100。

第二次握手：服务端收到客户端发过来的报文后，发现SYN=1，知道这是一个连接请求，于是将客户端的起始序列号100存起来，并且随机生成一个服务端的起始序列号(比

如是300)。然后给客户端回复一段报文，回复报文包含SYN和ACK标志(也就是SYN=1,ACK=1)、序列号seq=300、确认号ack=101(客户端发过来的序列号\+1)。

第三次握手：客户端收到服务端的回复后发现ACK=1并且ack=101,于是知道服务端已经收到了序列号为100的那段报文；同时发现SYN=1，知道了服务端同意了这次连接，

于是就将服务端的序列号300给存下来。然后客户端再回复一段报文给服务端，报文包含ACK标志位(ACK=1)、ack=301(服务端序列号\+1)、seq=101(第一次握手时发送报文

是占据一个序列号的，所以这次seq就从101开始，需要注意的是不携带数据的ACK报文是不占据序列号的，所以后面第一次正式发送数据时seq还是101)。当服务端收到报

文后发现ACK=1并且ack=301，就知道客户端收到序列号为300的报文了，就这样客户端和服务端通过TCP建立了连接。四次挥手的目的是关闭一个连接

比如客户端初始化的序列号ISA=100，服务端初始化的序列号ISA=300。TCP连接成功后客户端总共发送了1000个字节的数据，服务端在客户端发FIN报文前总共回复了2000个字

节的数据。

因为需要考虑连接时丢包的问题，如果只握手2次，第二次握手时如果服务端发给客户端的确认报文段丢失，此时服务端已经准备好了收发数(可以理解服务端已经连接成功)据，

而客户端一直没收到服务端的确认报文，所以客户端就不知道服务端是否已经准备好了(可以理解为客户端未连接成功)，这种情况下客户端不会给服务端发数据，也会忽略服务端

发过来的数据。

如果是三次握手，即便发生丢包也不会有问题，比如如果第三次握手客户端发的确认ack报文丢失，服务端在一段时间内没有收到确认ack报文的话就会重新进

行第二次握手，也就是服务端会重发SYN报文段，客户端收到重发的报文段后会再次给服务端发送确认ack报文。

因为只有在客户端和服务端都没有数据要发送的时候才能断开TCP。而客户端发出FIN报文时只能保证客户端没有数据发了，服务端还有没有数据发客户端是不知道的。而服务端

收到客户端的FIN报文后只能先回复客户端一个确认报文来告诉客户端我服务端已经收到你的FIN报文了，但我服务端还有一些数据没发完，等这些数据发完了服务端才能给客户

端发FIN报文(所以不能一次性将确认报文和

FIN报文发给客户端，就是这里多出来了一次)。

这里同样是要考虑丢包的问题，如果第四次挥手的报文丢失，服务端没收到确认 ack报文就会重发第三次挥手的报文，这样报文一去一回 长时间就是2MSL，所以需要等这么长

时间来确认服务端确实已经收到了。

TCP设有一个保活计时器，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小

时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故

障，接着就关闭连接。什么是HTTP，HTTP 与 HTTPS 的区别

HTTP 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范

**四次挥手**

第一次挥手：当客户端的数据都传输完成后，客户端向服务端发出连接释放报文(当然数据没发完时也可以发送连接释放报文并停止发送数据)，释放连接报文包含FIN标志位

(FIN=1)、序列号seq=1101(100+1+1000，其中的1是建立连接时占的一个序列号)。需要注意的是客户端发出FIN报文段后只是不能发数据了，但是还可以正常收数据；另外

FIN报文段即使不携带数据也要占据一个序列号。

第二次挥手：服务端收到客户端发的FIN报文后给客户端回复确认报文，确认报文包含ACK标志位(ACK=1)、确认号ack=1102(客户端FIN报文序列号1101+1)、序列号

seq=2300(300+2000)。此时服务端处于关闭等待状态，而不是立马给客户端发FIN报文，这个状态还要持续一段时间，因为服务端可能还有数据没发完。

第三次挥手：服务端将最后数据(比如50个字节)发送完毕后就向客户端发出连接释放报文，报文包含FIN和ACK标志位(FIN=1,ACK=1)、确认号和第二次挥手一样ack=1102、

序列号seq=2350(2300+50)。

第四次挥手：客户端收到服务端发的FIN报文后，向服务端发出确认报文，确认报文包含ACK标志位(ACK=1)、确认号ack=2351、序列号seq=1102。注意客户端发出确认报

文后不是立马释放TCP连接，而是要经过2MSL(最长报文段寿命的2倍时长)后才释放TCP连接。而服务端一旦收到客户端发出的确认报文就会立马释放TCP连接，所以服务端

结束TCP连接的时间要比客户端早一些。

发表评论取消回复

表情：

评论列表（有 0 条评论，48人围观）

还没有评论，来说两句吧...

相关阅读

相关 TCP报文的头部结构

TCP报文的头部结构 ACK：确认序号有效。 FIN：释放一个连接。 PSH：接收方应该尽快将这个报文交给应用层。 RST：重置连接。 SYN：发起一个新连

叁歲伎倆/ 2024年03月17日 10:38/ 0 赞/ 49 阅读

相关传输层协议（1）：TCP 报文结构

传输层位于 OSI 七层模型的第4层，也位于 TCP/IP 五层模型的第4层，如图5-1所示： ![format_png][] 图5-１传输层传输层

向右看齐/ 2023年07月10日 05:07/ 0 赞/ 29 阅读

相关 TCP 头部格式

TCP (Transmission Control Protocol) 1.面向连接的、可靠的、基于字节流的传输层通信协议。 2.数据传输时，将应用层的数据流分割成报

男娘i/ 2023年06月28日 06:27/ 0 赞/ 136 阅读

相关【计算机网络】TCP报文段结构

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ub

左手的ㄟ右手/ 2022年11月17日 05:04/ 0 赞/ 137 阅读

相关 Java. tcp报文长度_tcp，udp报文最大长度

tcp，udp报文最大长度是怎么样的呢？先来看看各个报文格式： ip报文 ![89eb46449a512d8a3dc3bc69de1ed6bc.png][] tcp报

╰半夏微凉°/ 2022年11月06日 04:57/ 0 赞/ 226 阅读

相关 TCP报文格式

TCP（Transmission Control Protocol）传输控制协议是一种面向连接的、可靠的、基于字节流的传输层协议 TCP报文格式： ![Center][]

曾经终败给现在/ 2022年07月17日 01:43/ 0 赞/ 208 阅读

相关 TCP报文发送工具

该工具用于向Socket服务端发送XML报文，软件功能界面如下图所示： ![这里写图片描述][20161015231039693] 配置好IP和端口后，单击“载入报文文

阳光穿透心脏的1/2处/ 2022年07月16日 10:49/ 0 赞/ 212 阅读

相关 TCP报文段结构

TCP协议的特点 TCP是可靠的、面向连接、面向字节流、支持双工（客户端和服务器端可以互相传输数据）、支持并发连接、提供确认重传与拥塞控制的传输层协议。添加补

分手后的思念是犯贱/ 2022年06月16日 02:07/ 0 赞/ 204 阅读

相关 TCP协议-RST报文

RST：（Reset the connection）用于复位因某种原因引起出现的错误连接，也用来拒绝非法数据和请求。如果接收到RST位时候，通常发生了某些错误；发送RST包

╰半橙微兮°/ 2022年06月08日 23:57/ 0 赞/ 468 阅读

相关 RTP报文头部分析

RTP报文格式 RTP报文由两部分组成：报头和有效载荷。RTP报头格式如下图所示，其中： l V：RTP协议的版本号，占2位，当前协议版本号为2。

清疚/ 2022年05月26日 03:28/ 0 赞/ 435 阅读