精华内容
下载资源
问答
  • 2022-03-17 08:41:22
    1、TCP协议

    在这里插入图片描述

    2、组成结构分析

    1、源端口号:发送方端口号
    2、目的端口号:接收方端口号
    3、序列号:报文段的数据的第一个字节的序号
    3、确认序号:期望收到对方下一个报文段的第一个数据字节的序号

    4、首部长度(数据偏移):TCP报文段的数据起始距离TCP报文段的起始处有多远,即首部长度
    6、保留:保留不用是置为0

    7、紧急URG:此置为 1 ,紧急指针字段才有效,它告诉系统此报文段中有紧急数据,应尽快传送
    8、确认位ACK:此置为 1,确认号字段才有效,TCP规定,在连接建立后所有传达的报文段都必须把 ACK 置 1
    9、推送位PSH:此置为 1,即发送方,希望接收方接收缓冲区的数据,即TCP使用推送(PUSH)操作,接收方不再等整个缓冲区填满后再交付
    10、复位RST:用于复位相应的TCP连接
    11、同步SYN:仅在三次握手建立TCP连接时有效,当SYN = 1 且 ACK = 0,表明 请求连接报文段,SYN = 1 且 ACK = 0,同意建立连接报文段
    12、终止FIN:用来释放连接,FIN = 1,表明此报文段的数据发送已经发送完毕,并要求释放连接

    13、窗口:指发送本报文段的一方的接受窗口(而不是自己的发送窗口)
    14、校验和:校验字段检验的范围(包括首部和数据两部分),计算校验和时需要加上 12 字节的伪头部
    15、紧急指针:仅在 URG = 1时才有意义,它代表本报文段中的紧急数据的字节数(紧急数据结束后就是普通数据),即指出紧急数据在报文末尾的位置,(注意:及时窗口为0 时也可以发送紧急数据)
    16、选项:长度可变,最长可达 40 字节,当没有使用选项时,TCP首部长度是 20 字节

    整理不易 你的点赞、关注是对我莫大的鼓励
    在这里插入图片描述

    更多相关内容
  • TCP是在IP网络层之上的传输层协议,用于提供port到port面向连接的可靠的字节流传输。我来用土语解释下上面的几个关键字:port到port:IP层只管数据包从一个IP到另一个IP的传输,IP层之上的TCP层加上端口后,就是面向...
  • TCP协议详解

    千次阅读 2021-12-26 10:54:32
    TCP协议 传输控制协议(TCP,Transmission Control Protocol)是一种面向连接的、可靠的、基于字节流的传输层通信协议,由IETF的RFC 793 定义。 TCP报文段 TCP建立连接的过程(三次握手) TCP拆除连接的过程(四次...

    TCP协议

    什么是TCP协议

    传输控制协议(TCP,Transmission ControlProtocol)是一种面向连接的、可靠的、基于字节流的传输层通信协议,由IETF的RFC 793 定义。TCP协议建立的是一种点到点的,一对一的可靠连接,与UDP相比以牺牲效率为代价换取高可靠性的服务。

    TCP报文段

    TCP报文段也叫TCP分组,是TCP协议传输和接收数据的一种封装格式,只有按照该格式发送的数据才可以被TCP协议通信的双方正确的接收与解析。

    在这里插入图片描述
    TCP报文的组成部分描述如下:

    • 源端口:标识源端应用进程,即发送TCP分组的进程端口号。
    • 目的端口:标识目的端应用进程,即需要接收分组数据的进程端口号。
    • 序号(seq):在SYN标志未置1时,该字段指示了用户数据区中的第一个字节的序列号;在SYN标志置1时,该字段指示的是初始发送的序列号。
    • 确认号(ACK):用来确认本端TCP实体已经接收到的数据,其值表示期待对端发送的下一个字节的序号,实际上告诉对方,这个序号减1以前的字节已经正确接收。例如发送确认号为1001,则表示前1000个字节已经被确认接收了。
    • 数据偏移:表示以 32bit为单位的TCP分组头的总长度,用于确定用户数据区的起始位置。
    • RST:连接复位,重新连接
    • SYN:同步序号,当SYN置1时,表示建立连接,分组将发送seq为初始序列号(其值一般随机)
    • FIN:结束标志,表示关闭连接,当该字段置1时,表示分组将要关闭连接
    • ACK:确认号有效的标志,置1时表示确认号有效。
    • URG:紧急指针有效的标志,置1时表示紧急指针有效
    • PSH:Push操作。

    TCP建立连接的过程(三次握手)

    在这里插入图片描述TCP连接的建立是通过三次握手的过程完成的,下面将具体讲解何为三次握手:

    第一次握手

    第一次握手由客户端服务器 发出:客户端发送一个TCP数据报,其中,TCP分组的源端口为客户端发起通信建立的进程端口,而目的端口为服务器处理请求的进程端口号,比如80端口。在表示建立连接的TCP分组中,SYN标志位为被置1,则告知服务器发送该分组的目的是请求建立连接,并且当SYN置1时,该分组中的seq字段发送的是初始序列号cilent_isn,初始序列号的取值方案有多种,一般取随机值。

    第二次握手

    第二次握手由服务器客户端发出:服务器在成功接收了客户端第一次握手发送的分组后,首先需要解析收到的TCP分组,发现SYN置1后,得知这个客户端发送分组的目的是为了建立连接,在确认完毕分组信息后,服务器也会向客户端发送一个TCP分组来代表第二次握手。

    这个由服务器发送的TCP分组包含以下内容

    • 首先将代表建立连接目的的SYN标志位同样置1
    • 然后随机地产生服务器端的初始序列号 server_isn在seq字段中发送
    • 同时将代表累计确认接收字节位数的ACK确认号发送,该确认号ACK的值为客户端发送的TCP分组中的初始序列号+1,即cilent_isn+1。也就是发送服务器期望接收的下一个字节序号。

    第三次握手

    第三次握手由客户端向服务器发出:客户端在接收到服务器第二次握手的回复之后,同样会接收来自于服务器的TCP分组并进行解读:由SYN为1解读该TCP分组的目的是继续建立连接,由分组中的ACK确认号了解到服务器已经成功接收了前cilent_isn个字节的内容,并期望接收第cilent_isn+1个字节的字节序号,同时累计确认来自服务器的初始序列号。并发送最后一个TCP分组给服务器来完成第三次握手。

    这个由客户端发送给服务器的最后一个TCP分组的内容有:

    • 代表继续建立连接的SYN为1
    • 发送服务器期望接收的值为cilent_isn+1的序列号字段seq
    • 发送期望接收到的下一个字节的序列号,也就是确认号ACK,值为server_isn+1

    为什么需要三次握手

    为什么TCP的连接必须进行三次握手,而不是一次或两次?

    为了防止建立重复的连接而损耗资源或造成其他问题

    谢希仁版《计算机网络》中的例子:“已失效的连接请求报文段”的产生在这样一种情况下:client发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后,就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段,同意建立连接。假设不采用“三次握手”,那么只要server发出确认,新的连接就建立了。由于现在client并没有发出建立连接的请求,因此不会理睬server的确认,也不会向server发送数据。但server却以为新的运输连接已经建立,并一直等待client发来数据。这样,server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况,client不会向server的确认发出确认。server由于收不到确认,就知道client并没有要求建立连接。”

    也就是说,假如只采用两次握手,会让因网络错误延时到达的客户端连接请求被服务器接收时,服务器无从得知这是一个失效的请求而与客户端建立一个无效的连接。在三次握手机制的情形下,这样无效的请求分组会被返回给客户端来确认,而客户端不在等待该由该分组产生第三次握手的状态,服务器得不到客户端的回应,等待超时后会取消本次连接的建立。从而避免了错误连接的建立

    TCP拆除连接的过程(四次挥手)

    四次握手的连接关闭过程与三次握手相类似:
    在这里插入图片描述四次挥手的过程简述如下:

    第一次挥手: 客户端因为不再有数据发送给服务器,所以向服务器发送FIN报文表示想要关闭连接,不会再发送数据了。同时包含客户端的报文序号M

    第二次挥手: 服务器在接收了来自客户端的FIN报文后,得知客户端不再发送数据,将要关闭连接。但是,此时服务器端获取还有部分数据没有回传给客户端,服务器可能还要向客户端发送一部分数据才能关闭连接。所以服务器不会立马同意关闭连接,而是先发送表示确认信息的ACK报文,该ACK报文中包含了值为M+1的确认号。

    第三次挥手: 在服务器端完成向客户端传送最后的数据后,此时不再有数据需要传输了。那么服务器也准备关闭连接,所以向客户端发送表示关闭连接的FIN报文,报文中包含了服务器端的序号N

    第四次挥手: 在客户端也收到了服务器端发送的FIN报文之后,得知服务器端也可以关闭连接了,此时再向服务器发送最后一次确认报文ACK,使连接成功关闭,ACK报文中的确认号为N+1

    为什么需要四次挥手?

    为什么需要中间两次挥手?
    为什么需要其中的第二次和第三次的原因其实已经提到,假如在服务器收到客户端的第一次挥手就准备关闭连接发送FIN报文,不再发送数据。那么只是客户端单方面提出了中断通信的请求而导致连接关闭,使服务器中要发往客户端的最后数据不能正常传送,会导致通信不完整。
    为什么需要第四次挥手?
    第四次挥手同样是用来解决一个因网络时延滞后到达的失效请求的问题。
    请分析这样一个情形:即假如客户端一次发送了两个关闭请求,其中一个滞后了很久才到达,此时它们当时建立的连接已经被第一个请求关闭。而服务器又再次和客户端建立了新的连接,并且此时不需要关闭,但是这个失效的关闭请求滞后到达了。

    • 假如没有最后一次挥手,那么服务器以为客户端要关闭连接,一次发送ACK和FIN报文后连接就被错误关闭了,这样显然是存在问题的。

    • 假如有最后一次握手,服务器在收到失效报文后仍然会发送ACK和FIN报文给客户端来确认客户端是否真的要关闭连接。而客户端此时的状态并不是等待关闭连接的状态,所以不会给服务器发送ACK报文进行关闭连接的确认回复,服务器在等待一段时间超时后会取消连接的关闭,从而不会因为失效的报文让连接错误地关闭。

    TCP发送数据的过程(超时和重传)

    在这里插入图片描述TCP数据的发送过程也与建立连接的过程相类似:
    发送数据的过程采用了累计确认的机制,其中ACK表示的是累积确认的字节序号。
    如上图,发送的TCP分组中可以包含数据,也可以不包含数据,但是一定需要包含seq序号和确认号。seq序号表示数据区中第一个字节的序号,而回传的ack确认号的值为seq的值加上发送的数据字节数。表示这些字节的数据已经被确认接受了,并表达了期望接收的下一个字节序号位置。

    在这里插入图片描述
    在这里插入图片描述发送TCP分组的一方会在发送分组时设置超时时间并开启计时器,当在超时时间内未收到该分组的ACK回复时,会认为该分组丢失,并重发该分组。假如之前的分组被连续发送,而该分组及之后的分组已经被接收端确认,那么本次重复分组收到的ACK是累计确认的字节序号值,而非该分组的seq+数据字节数,如上图右侧所示。

     
     
     

    感谢阅读,求关注收藏,等期末考试结束后会再出关于TCP流量控制和拥塞控制等方面更加详细的内容。超链接写好后会附在下面。
    本文参考了哈工大mooc计算机网络的内容

    展开全文
  • TCP 协议头全解

    千次阅读 2022-04-02 18:30:50
    本文将带你学会 1. 从 wireshark 中来看面试中常问的 tcp 三次握手 四次挥手 真正的数据面目到底是什么? 2. 看到 TCP/IP 五层模型的具象化真实表达 3. 网络传输中 TCP 头全解析

    TCP 协议头全解

    写在前面

    好久没有写在前面了,这次写下。很久没有更新,csdn 估计要忘了我了,排名一直在掉,提笔写这篇文章,说实话,从题目定了,到下笔,中间大概有 3 天之久,到完成可能还更晚。一来是最近可能有点忙,二来有点不知道该如何提笔了,有时候在想 ”意义“ 二字。有时会颓然觉得,所思所想所做,都无甚大意义,大抵如此。

    说回技术文章,我看技术文章有个毛病,看长篇大论,很容易就不想看了,密密麻麻写了一堆,我靠,我根本不想看好嘛。

    然鹅,到我写的时候,也不可避免的会堆一些学术文档来说明。确实很恶心,但又有啥办法呢,为了能够明确主题和主旨,所以加个模块 《本文将带你学会》总结一下我这篇文章将为你带来什么,你能从这里 get 到什么。避免大家浪费时间是不。

    文章我尽量写的简洁一点,把我在学习过程中疑惑的点整理出来。

    害,干货啊干货,前有干货,所以,三连很有用。

    本文将带你学会

    1. 从 wireshark 中来看面试中常问的 tcp 三次握手 四次挥手 真正的数据面目到底是什么?

    2. 看到 TCP/IP 五层模型的具象化真实表达

    3. 网络传输中 TCP 头全解析

    我用 wireshark 抓了我的接口

    从 wireshark 看 ”三次握手“ 和 ”四次挥手“

    首先带你们看看,一次接口请求,在网络中都经历了什么
    在这里插入图片描述

    上图,三次握手 建立连接,请求接口传输数据。这个时候请求结束,TCP 进行了一波 Keep-Alive

    在这里插入图片描述

    最后服务端向我请求端发起了断链,进行了四次挥手 断开连接。

    三次握手建立连接,四次挥手断开连接。这个我们在后面讲为什么要这么做。重点看数据包中都发了写什么

    首先拿第一个 SYN 请求连接包来举例看

    在这里插入图片描述

    这里可以具象化地看到,我们所谓的分层都是些什么东西,他们的实际表现形式

    TCP/IP 五层最终的表达是什么?

    物理层: Frame 11561: 78 bytes on wire (624 bits), 78 bytes captured (624 bits) on interface en0, id 0

    数据链路层: Ethernet II, Src: Apple_cb:e5 (90::cb:ec:c5), Dst: Huaa:04 (ac:7:40:ea:04)

    网络层: Internet Protocol Version 4, Src: 172.16.25.144, Dst: 192.168.26.144

    传输层: Transmission Control Protocol, Src Port: 58173, Dst Port: 18080, Seq: 0, Len: 0

    应用层: 这里没有,下面 HTTP 协议就有了

    看一眼,HTTP 的
    在这里插入图片描述

    应用层: Hypertext Transfer Protocol

    看到这里有些蒙的同学可以看看我之前的文章,补补课复习一下

    网络编程之 Socket 编程 一文看懂

    网络分层流转—从浏览器请求到服务端响应究竟经历了什么?

    本篇重点是 传输层协议 TCP ,篇幅问题,就不节外生枝,直接走主线

    Transmission Control Protocol 中都存了什么

    在这里我要放一下,网络上都放烂了的图,当然我会抄一遍,用自己的形式展示出来 [狗头]
    在这里插入图片描述

    给了图,不解释下什么意思,就是耍流氓了,这里大概给个解释,让大家对这个设计有个理解

    源端口号 Source Port: 一般来说就是客户端发起请求时使用的端口号,这个在浏览其发起请求时会自动分配一个。比如这里我被分配的端口号就是 58173。这个作用是服务端给你返回数据的时候能找到你客户端的端口

    目的端口号 Destintion Port: 这个就是你要访问的服务的端口号,比较常用的如 8080 ,我这里是 18080。同理,你请求到了服务端总要知道服务是由哪个端口提供的吧。

    序号 Sequence Number: TCP 为了保证包的顺序到达,就需要给每个包一个需要来标识它的顺序,它解决了乱序的问题,当然这个逻辑也是在两端程序逻辑控制的,真正的包到了网络中是怎么样的,那对你来说可就是鞭长莫及干瞪眼了。(祈祷他能平安到达吧)

    关于序号的生成规则

    TCP 是面向字节流的,这意味着 TCP 在传输数据的过程中会为每个字节按照顺序进行编号。例如对于传输 10 kb 的 HTML 文档

    10 kb = 10 * 1024 byte = 10240 byte 一共 10240 个字节。

    序号是 32 位 是 2^32 是 4 294 967 296 = 4G 所以 TCP 可以对 4G 的数据进行编号,超过之后回 0 重新计数

    那对于上面的 10 kb 其编号范围就是 [0,10239]

    这里的序号标识的是此报文段中,数据的第一个字节的序号,如上述 10 kb 数据我们分成两等分传输

    第一段: 5 kb Sequence Number = 0 ; 其范围是 [0,5119]

    第二段: 5 kb Sequence Number = 5120 ; 其范围是 [5120,10239]

    相信大家可能注意到了一点,超出 4G 重复使用编号的问题,这种情况其实基本不用担心,一般情况,旧的序号早就到达终点,或者丢失了。

    确认序号 Acknowledgement Number: 为了保证可靠性,发出去的包需要确认到达,就有了确认序号,这个解决了丢包的问题,一定时间没确认收到就重发嘛。我们 TCP 能做啥呢,就是不断的重传,寄希望于能得到对端的收到确认,卑微也就至此了。

    同样的 32 位确认序号,表示的是 期望收到对方下一个报文的序号值。

    TCP 的可靠就是基于此,我们要确认每个发送出的报文都被确认收到了。

    通讯双方在接到对方的报文后,都需要发送一个对应的确认报文,要告知已经收到,有确认报文就需要确认好

    如第一段: 5 kb Sequence Number = 0 ; 其范围是 [0,5119] 发送过来,此时回 ACK 确认报文 Acknowledgement Number = 5120

    标志位 Flags: 标志位共 16 位,首部占 4 位,保留 6 位,剩余 6 位每没一位标志不同的意思

    1. 首部 Header Length 4 位,表示 TCP 报文段首部长度,看了下有的地方也叫它数据偏移,可以理解为 TCP 报文起始位置 到 数据部分 payload 的起始位置 也就是上图中 [源端口号 , 选项, 填充 ] 这部分数据的大小,4 位 0000 最大为 1111 = 15 ,这里每个数代表 4 byte,所以首部最大是 15 * 4 byte = 60 byte
    2. 保留 6 位 保留 6 位默认给 0,用于之后的拓展
    3. 标志位 目前 6 位下图,0 表示没有,1 表示标识,每位代表不同含义
      1. 紧急 Urgent URG 该位为 1 表示后面要说到的 紧急指针 有效,用于告诉系统,此报文段中包含紧急数据,应该尽快传送,而不是按原有顺序排队传,紧急吗,就是要加急传输。
      2. 确认 Acknowledgment ACK 该位为 1 表示确认序号 Acknowledgement Number 有效,一般称携带 ACK 标志的 TCP 报文段称为确认报文段,TCP 规定在建立连接后所有的传输报文都必须报 ACK 设置为 1
      3. 推送 Push PUS 该位为 1 表示该报文高优先级,接收方 TCP 应该尽快将其推送给应用服务,而不用等到 TCP 缓存填满后再一起发送
      4. 复位 Reset RST 该位为 1 表示在 TCP 连接中出现了严重的错误,需要释放并重新建立连接,一般携带 RST 标志的报文段称之为 复位报文段
      5. 同步 Syn SYN 该位用于标识此报文为同步报文,SYN = 1 ACK = 0 表示此次是 请求建立连接报文段,如果对方同意建立连接,则会返回一个 SYN = 1 ACK = 1 的响应报文。
      6. 终止 Fin FIN 用于标识断开连接,为 1 是表示此报文的数据发送方数据已发送完毕,请求断开释放连接,这个在 ”四次挥手“ 时会用到。

    在这里插入图片描述

    窗口大小 Window : 16 位,该字段指定此时允许对方发送的最大数据量,也就是说此数据是我方缓冲区剩余大小,用于控制发送数据的速度

    窗口大小是指,从本端报文的 确认序号 Acknowledgment Number 开始,还允许对方发送的数据量。

    比如 Acknowledgment Number = 100 Window = 60 ,那么标识报文发送方还有 60 字节的接收空间,即序号范围是 [100,159] 的数据。

    校验和 CheckSum: 16 位 用于检测 TCP 报文段在传输过程中有没有损坏,如果损耗则丢弃,采用 CRC 算法,这个是保证 TCP 可靠传输的重要一环。 具体生成校验规则,感兴趣同学可以自行搜索算法。

    紧急指针 Urgent Pointer: 16 位 ,当标志位 URG 为 1 时有意义,用于指出报文段中紧急数据的字节数。发送方会将紧急数据插入到本次报文段的最前面,而后面的仍然是普通数据,紧急指针指示的是紧急数据的末尾在本段报文数据的位置。

    给你们看看 16 进制表示,而老说的位 ”01010101“ 而进制传输本质是 01 嘛,为啥不给你看 01 ? 因为不好看哈哈

    在这里插入图片描述

    不想写了,本文到这,下期再见

    展开全文
  • TCP协议

    千次阅读 2022-04-10 23:22:21
    RST 占1位,置位RST=1表示复位TCP连接;用于重置一个已经混乱的连接,也可用于拒绝一个无效的数据段或者拒绝一个连接请求。如果数据段被设置了RST位,说明报文发送方有问题发生。 SYN 占1位,在连接建立时用来...

    一.TCP协议

    传输控制协议(TCP,Transmission Control Protocol)是一种面向连接的、可靠的、基于字节流的传输层通信协议。

    特点:

    1)基于流的方式;

    (2)面向连接;(在通信之前要通过三次握手建立链接)

    (3)可靠通信方式;(确保数据不会丢失)

    (4)在网络状况不佳的时候尽量降低系统由于重传带来的带宽开销;(拥塞控制)

    (5)通信连接维护是面向通信的两个端点的,而不考虑中间网段和节点。

    因为有着拥塞控制和可靠数据传输的要求所以导致了TCP协议的传输效率相对于UDP要低,但是不会像UDP一样出现丢包现象。

    二.TCP协议的报文格式

    在这里插入图片描述

    首先来解释一下端口号及其作用:首先我们要知道当两个不同主机之间的进程要实现通信的时候实际上是通过socket(套接字接口)来实现的。所谓的套接字就是同一台主机内应用层与运输层之间的接口。对于发送端,应用层将数据发送给套接字再由套接字送至运输层,在接收端,套接字从运输层中读取数据,在将其发送给应用层。

    那么问题来了,当一个套接字收到数据或者是发送数据的时候,怎么才能判断到底是什么服务的数据。(是电子邮件的服务,还是文件传输的服务等等)因此我们引入了端口号(port)来标识具体的服务,也就是说一个具体的端口号对应了一种具体的服务,而套接字正是通过识别不同的端口号来达到区分服务的目的。

    1.源端口号:报文的发送端口

    2.目的端口号:报文的就收端口

    3.序号(seq)确认号(ack):这两个字段及其重要。TCP的可靠数据传输主要就是依赖于这两个字段

    序号(Sequence Number):TCP传输过程中,在发送端出的字节流中,传输报文中的数据部分的每一个字节都有它的编号。

    序号(Sequence Number)的语义与SYN控制标志(Control
    Bits)的值有关。根据控制标志(Control Bits)中的SYN是否为1,序号(Sequence
    Number)表达不同的含义:

    (1)当SYN = 1时,当前为连接建立阶段,此时的序号为初始序号ISN((Initial Sequence
    Number),通过算法来随机生成序号;

    (2)当SYN = 0时在数据传输正式开始时,第一个报文的序号为 ISN +
    1,后面的报文的序号,为前一个报文的SN值+TCP报文的净荷字节数(不包含TCP头)。比如,如果发送端发送的一个TCP帧的净荷为12byte,序号为5,则发送端接着发送的下一个数据包的时候,序号的值应该设置为5+12=17。

    确认序号(AcknowledgmentNumber):

    标识了报文接收端期望接收的字节序列。如果设置了ACK控制位,确认序号的值表示一个准备接收的包的序列码,注意,它所指向的是准备接收的包,也就是下一个期望接收的包的序列码。

    4.控制标志位

    控制标志(Control
    Bits)共6个bit位,具体的标志位为:URG、ACK、PSH、RST、SYN、FIN。6个标志位的说明,如下表所示。
    URG    占1位,表示紧急指针字段有效。URG位指示报文段里的上层实体(数据)标记为“紧急”数据。当URG=1时,其后的紧急指针指示紧急数据在当前数据段中的位置(相对于当前序列号的字节偏移量),TCP接收方必须通知上层实体。
    ACK    占1位,置位ACK=1表示确认号字段有效;TCP协议规定,接建立后所有发送的报文的ACK必须为1;当ACK=0时,表示该数据段不包含确认信息。当ACK=1时,表示该报文段包括一个对已被成功接收报文段的确认序号Acknowledgment Number,该序号同时也是下一个报文的预期序号。
    PSH    占1位,表示当前报文需要请求推(push)操作;当PSH=1时,接收方在收到数据后立即将数据交给上层,而不是直到整个缓冲区满。
    RST    占1位,置位RST=1表示复位TCP连接;用于重置一个已经混乱的连接,也可用于拒绝一个无效的数据段或者拒绝一个连接请求。如果数据段被设置了RST位,说明报文发送方有问题发生。
    SYN    占1位,在连接建立时用来同步序号。当SYN=1而ACK=0时,表明这是一个连接请求报文。对方若同意建立连接,则应在响应报文中使SYN=1和ACK=1。 综合一下,SYN置1就表示这是一个连接请求或连接接受报文。
    FIN    占1位,用于在释放TCP连接时,标识发送方比特流结束,用来释放一个连接。当 FIN = 1时,表明此报文的发送方的数据已经发送完毕,并要求释放连接。

    在连接建立的三次握手过程中,若只是单个SYN置位,表示的只是建立连接请求。如果SYN和ACK同时置位为1,表示的建立连接之后的响应.

    5.窗口大小:

    长度为16位,共2个字节。此字段用来进行流量控制。流量控制的单位为字节数,这个值是本端期望一次接收的字节数。

    6.检验和:

    长度为16位,共2个字节。对整个TCP报文段,即TCP头部和TCP数据进行校验和计算,接收端用于对收到的数据包进行验证。

    三.TCP的三次握手和四次挥手

    三次握手过程
    TCP连接的建立时,双方需要经过三次握手,具体过程如下:

    (1)第一次握手:Client进入SYN_SENT状态,发送一个SYN帧来主动打开传输通道,该帧的SYN标志位被设置为1,同时会带上Client分配好的SN序列号,该SN是根据时间产生的一个随机值,通常情况下每间隔4ms会加1。除此之外,SYN帧还会带一个MSS(最大报文段长度)可选项的值,表示客户端发送出去的最大数据块的长度。

    (2)第二次握手:Server端在收到SYN帧之后,会进入SYN_RCVD状态,同时返回SYN+ACK帧给Client,主要目的在于通知Client,Server端已经收到SYN消息,现在需要进行确认。Server端发出的SYN+ACK帧的ACK标志位被设置为1,其确认序号AN(Acknowledgment
    Number)值被设置为Client的SN+1;SYN+ACK帧的SYN标志位被设置为1,SN值为Server端生成的SN序号;SYN+ACK帧的MSS(最大报文段长度)表示的是Server端的最大数据块长度。

    (3)第三次握手:Client在收到Server的第二次握手SYN+ACK确认帧之后,首先将自己的状态会从SYN_SENT变成ESTABLISHED,表示自己方向的连接通道已经建立成功,Client可以发送数据给Server端了。然后,Client发ACK帧给Server端,该ACK帧的ACK标志位被设置为1,其确认序号AN(Acknowledgment
    Number)值被设置为Server端的SN序列号+1。还有一种情况,Client可能会将ACK帧和第一帧要发送的数据,合并到一起发送给Server端。

    (4)Server端在收到Client的ACK帧之后,会从SYN_RCVD状态会进入ESTABLISHED状态,至此,Server方向的通道连接建立成功,Server可以发送数据给Client,TCP的全双工连接建立完成。

    三次握手的图解
    三次握手的交互过程,具体如下图所示:


    在这里插入图片描述

     

    Client和Server完成了三次握手后,双方就进入了数据传输的阶段。数据传输完成后,连接将断开,连接断开的过程需要经历四次挥手。

    TCP的四次挥手
    业务数据通信完成之后,TCP连接开始断开(或者拆接)的过程,在这个过程中连接的每个端的都能独立地、主动的发起,断开的过程TCP协议使用了四路挥手操作。

    四次挥手具体过程
    四次挥手具体过程,具体如下:

    (1)第一次挥手:主动断开方(可以是客户端,也可以是服务器端),向对方发送一个FIN结束请求报文,此报文的FIN位被设置为1,并且正确设置Sequence
    Number(序列号)和Acknowledgment
    Number(确认号)。发送完成后,主动断开方进入FIN_WAIT_1状态,这表示主动断开方没有业务数据要发送给对方,准备关闭SOCKET连接了。

    (2)第二次挥手:正常情况下,在收到了主动断开方发送的FIN断开请求报文后,被动断开方会发送一个ACK响应报文,报文的Acknowledgment
    Number(确认号)值为断开请求报文的Sequence Number
    (序列号)加1,该ACK确认报文的含义是:“我同意你的连接断开请求”。之后,被动断开方就进入了CLOSE-WAIT(关闭等待)状态,TCP协议服务会通知高层的应用进程,对方向本地方向的连接已经关闭,对方已经没有数据要发送了,若本地还要发送数据给对方,对方依然会接受。被动断开方的CLOSE-WAIT(关闭等待)还要持续一段时间,也就是整个CLOSE-WAIT状态持续的时间。

    主动断开方在收到了ACK报文后,由FIN_WAIT_1转换成FIN_WAIT_2状态。

    (3)第三次挥手:在发送完成ACK报文后,被动断开方还可以继续完成业务数据的发送,待剩余数据发送完成后,或者CLOSE-WAIT(关闭等待)截止后,被动断开方会向主动断开方发送一个FIN+ACK结束响应报文,表示被动断开方的数据都发送完了,然后,被动断开方进入LAST_ACK状态。

    (4)第四次挥手:主动断开方收在到FIN+ACK断开响应报文后,还需要进行最后的确认,向被动断开方发送一个ACK确认报文,然后,自己就进入TIME_WAIT状态,等待超时后最终关闭连接。处于TIME_WAIT状态的主动断开方,在等待完成2MSL的时间后,如果期间没有收到其他报文,则证明对方已正常关闭,主动断开方的连接最终关闭。

    被动断开方在收到主动断开方的最后的ACK报文以后,最终关闭了连接,自己啥也不管了。


    四次挥手的全部交互过程,具体如下图所示:

    在这里插入图片描述

     

    处于TIME_WAIT状态的主动断开方,在等待完成2MSL的时间后,才真正关闭连接通道,其等待的时间为什么是2MSL呢?

    2MSL翻译过来就是两倍的MSL。MSL全称为Maximum Segment
    Lifetime,指的是一个TCP报文片段在网络中最大的存活时间,具体来说,2MSL对应于一次消息的来回(一个发送和一个回复)所需的最大时间。如果直到2MSL,主动断开方都没有再一次收到对方的报文(如FIN报文),则可以推断ACK已经被对方成功接收,此时,主动断开方将最终结束自己的TCP连接。所以,TCP的TIME_WAIT状态也称为2MSL等待状态。

    有关MSL的具体的时间长度,在RFC1122协议中推荐为2分钟。在SICS(瑞典计算机科学院)开发的一个小型开源的TCP/IP协议栈——LwIP开源协议栈中MSL默认为1分钟。在源自Berkeley的TCP协议栈实现中MSL默认长度为30秒。总体来说,TIME_WAIT(2MSL)等待状态的时间长度,一般维持在1-4分钟之间。

    通过三次握手建立连接和四次挥手拆除连接,一次TCP的连接建立及拆除,至少进行7次通信,可见其成本是很高的。

    三次握手、四次挥手的常见面试题
    有关TCP的连接建立的三次握手及拆除过程的四次挥手的面试问题,是技术面试过程中的出现频率很高的重点和难点问题,常见问题大致如下:

    问题(1):为什么关闭连接的需要四次挥手,而建立连接却只要三次握手呢?
    关闭连接时,被动断开方在收到对方的FIN结束请求报文时,很可能业务数据没有发送完成,并不能立即关闭连接,被动方只能先回复一个ACK响应报文,告诉主动断开方:“你发的FIN报文我收到了,只有等到我所有的业务报文都发送完了,我才能真正的结束,在结束之前,我会发你FIN+ACK报文的,你先等着”。所以,被动断开方的确认报文,需要拆开成为两步,故总体就需要四步挥手。

    而在建立连接场景中,Server端的应答可以稍微简单一些。当Server端收到Client端的SYN连接请求报文后,其中ACK报文表示对请求报文的应答,SYN报文用来表示服务端的连接也已经同步开启了,而ACK报文和SYN报文之间,不会有其他报文需要发送,故而可以合二为一,可以直接发送一个SYN+ACK报文。所以,在建立连接时,只需要三次握手即可。

    问题(2):为什么连接建立的时候是三次握手,可以改成两次握手吗?
    三次握手完成两个重要的功能:一是双方都做好发送数据的准备工作,而且双方都知道对方已准备好;二是双方完成初始SN序列号的协商,双方的SN序列号在握手过程中被发送和确认。

    如果把三次握手改成两次握手,可能发生死锁。两次握手的话,缺失了Client的二次确认ACK帧,假想的TCP建立的连接时二次挥手,可以如下图所示:


    在这里插入图片描述

     

    在假想的TCP建立的连接时二次握手过程中,Client发送Server发送一个SYN请求帧,Server收到后发送了确认应答SYN+ACK帧。按照两次握手的协定,Server认为连接已经成功地建立了,可以开始发送数据帧。这个过程中,如果确认应答SYN+ACK帧在传输中被丢失,Client没有收到,Client将不知道Server是否已准备好,也不知道Server的SN序列号,Client认为连接还未建立成功,将忽略Server发来的任何数据分组,会一直等待Server的SYN+ACK确认应答帧。而Server在发出的数据帧后,一直没有收到对应的ACK确认后就会产生超时,重复发送同样的数据帧。这样就形成了死锁。

    问题(3):为什么主动断开方在TIME-WAIT状态必须等待2MSL的时间?
    原因之一:主动断开方等待2MSL的时间,是为了确保两端都能最终关闭。假设网络是不可靠的,被动断开方发送FIN+ACK报文后,其主动方的ACK响应报文有可能丢失,这时候的被动断开方处于LAST-ACK状态的,由于收不到ACK确认被动方一直不能正常的进入CLOSED状态。在这种场景下,被动断开方会超时重传FIN+ACK断开响应报文,如果主动断开方在2MSL时间内,收到这个重传的FIN+ACK报文,会重传一次ACK报文,后再一次重新启动2MSL计时等待,这样,就能确保被动断开方能收到ACK报文,从而能确保被动方顺利进入到CLOSED状态。只有这样,双方都能够确保关闭。反过来说,如果主动断开方在发送完ACK响应报文后,不是进入TIME_WAIT状态去等待2MSL时间,而是立即释放连接,则将无法收到被动方重传的FIN+ACK报文,所以不会再发送一次ACK确认报文,此时处于LAST-ACK状态的被动断开方,无法正常进入到CLOSED状态。

    原因之二:防止“旧连接的已失效的数据报文”出现在新连接中。主动断开方在发送完最后一个ACK报文后,再经过2MSL,才能最终关闭和释放端口,这就意味着,相同端口的新TCP新连接,需要在2MSL的时间之后,才能够正常的建立。2MSL这段时间内,旧连接所产生的所有数据报文,都已经从网络中消失了,从而,确保了下一个新的连接中不会出现这种旧连接请求报文。

    问题(4):如果已经建立了连接,但是Client端突然出现故障了怎么办?
    TCP还设有一个保活计时器,Client端如果出现故障,Server端不能一直等下去,这样会浪费系统资源。每收到一次Client客户端的数据帧后,Server端都的保活计时器会复位。计时器的超时时间通常是设置为2小时,若2小时还没有收到Client端的任何数据帧,Server端就会发送一个探测报文段,以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应,Server端就认为Client端出了故障,接着就关闭连接。如果觉得保活计时器的两个多小时的间隔太长,可以自行调整TCP连接的保活参数。

    原文链接:https://blog.csdn.net/crazymakercircle/article/details/114527369

     

    展开全文
  • TCP协议工作机制详解

    千次阅读 2022-03-21 18:45:20
    TCP协议 确认应答 超时重传 连接管理 滑动窗口 流量控制 拥塞控制 延迟应答 捎带应答 粘包问题 异常情况
  • Linux:TCP协议的特点

    千次阅读 2022-02-23 21:06:22
    TCP协议的特点
  • TCP协议和UDP协议

    千次阅读 2021-12-09 08:57:31
    2,TCP协议传输是可靠的,UDP协议传输“尽力而为”; 3,TCP可以进行流控,UDP不行; 4,TCP可以进行分段,UDP不行; 5,TCP传输速度较慢,占用资源较大;UDP传输速度较快,占用资源小; 扔球游戏 1.面向连接...
  • TCP协议-TCP连接管理

    千次阅读 2021-07-13 16:07:28
    TCP协议是 TCP/IP 协议族中一个非常重要的协议。它是一种面向连接、提供可靠服务、基于字节流的传输层通信协议。 TCP(Transmission Control Protocol,传输控制协议)。 1.1 TCP协议的特点 (1)TCP 是面向...
  • 关于TCP协议,我想你应该懂了!

    千次阅读 2021-08-11 07:03:45
    程序员TCP(Transmission Control Protocol 传输控制协议)是一种面向链接(链接导向)的、可靠的、 基于IP的传输层协议TCP在IP报文的协议号是6。TCP是一个超级麻烦的协议,而它又是互联网的基础,也是每一个程序员...
  • UDP/TCP 协议详解

    2022-02-23 02:40:13
    目录UDP / TCPUDP 协议UDP的特点UDP协议格式UDP的缓冲区TCP 协议TCP 协议报头确认应答(ACK)机制超时重传机制 UDP 协议 UDP的特点 无连接 一旦得知接收端的IP和端口号就可以加个报头直接向下层交付进行传输,不...
  • TCP协议分析

    2020-09-17 20:23:11
    目录 TCP简介 TCP首部格式 建立连接 ...为什么建立连接是三次而断开连接是四次呢?...我们所熟悉的FTP,SSH,HTTP,HTTPS,SMTP,POP3等都是使用TCP协议。 TCP最重要的一个特点就是面向连接的协议,.
  • 传输层 3.tcp协议 3.1、TCP封装格式 3.2、三次握手 3.3、四次断开 3.4、TCP的差错控制 3.5、TCP的拥塞控制 3.6、计时器 4.UDP协议 5.经典的端口号 6.学习中的问题 7.转摘 1.iptables iptables 是一个防火墙工具 ...
  • 一、TCP 协议 特点、 二、TCP 报文段首部格式、 三、TCP 报文段首部 66 控制位、
  • TCP协议格式和特点

    千次阅读 2022-04-22 11:05:41
    文章目录1.协议格式:2.协议特性:2.1 面向链接2.1.1三次握手建立连接2.1.1四次挥手断开连接相关问题和知识点...7. TCP的保活机制(心跳探测)2.2 可靠传输2.2.1 安全有序传输(保证数据可靠到达对端并且有序进行交付)1
  • 如何快速理解TCP协议

    千次阅读 2022-03-24 18:51:00
    TCP全称位”传输控制协议(Transmission Control Protocol)“。 TCP是在传输层中 TCP是有连接的协议;”三次握手和四次握手 “ TCP是可靠的 TCP是面向字节流的 TCP的报文格式 源端口号和目的端口号:表示数据从...
  • \qquad (2) 每一条TCP连接只能有两个端点,每一条TCP连接只能是点对点的,所以TCP协议不能进行广播和多播; \qquad (3) TCP提供可靠交付的服务,无差错,不丢失,不重复,按序到达; \qquad (4) TCP提供全双工通信,...
  • TCP协议从入门到精通

    千次阅读 2022-02-22 02:20:42
    文章目录TCP协议TCP头部信息TCP头部信息清单16位端口号(port number)32位序号(sequence number)32位确认号(acknowledgement number)4位头部长度(header length)6位标志位16位窗口大小(window size)16位...
  • TCP面向连接,提供可靠的服务,有流量控制,拥塞控制,无重复、无丢失、无差错,面向字节流(把应用层传下来的报文看成字节流,把字节流组织成大小不等的数据块),只能是点对点,首部20字节,全双工。 1.tcp首部...
  • 网络协议分析-TCP协议分析

    千次阅读 2020-01-06 21:13:43
    TCP协议的应用 TCP包结构 源端口号( 16 位):它(连同源主机 IP 地址)标识源主机的一个应用进程。 目的端口号( 16 位):它(连同目的主机 IP 地址)标识目的主机的一个应用进程。这两个值加上 IP 报头中的源...
  • TCP协议详解 (史上最全)

    万次阅读 多人点赞 2021-03-08 12:27:36
    传输层TCP协议提供了一种面向连接的、可靠的字节流服务,其数据帧格式,大致如下图所示: 图:传输层TCP协议的数据帧格式 一个传输层TCP协议的数据帧,大致包含以下字段: (一)源端口号 源端口号表示报文的发送...
  • TCP概述-可靠的、面向连接的、基于字节流、全双工的协议TCP 是面向连接的协议三次握手TCP 协议是可靠的TCP 是面向字节流的协议TCP 是全双工的协议小结与思考packetdrill-google协议栈测试神器-TODO详解tcp基石-剖析...
  • Wireshark数据抓包分析之传输层协议(TCP协议) 本实验主要介绍了利用wireshark进行数据抓包并分析TCP协议,通过本实验的学习,你能够熟悉并掌握Wireshark的基本操作,加深对常用网络协议的理解。 实验简介 实验所属...
  • UDP和TCP协议详解

    千次阅读 2021-03-19 09:44:09
    一. 引言 网络协议是每个程序员都要掌握的基础知识,干啥都离不开网络,就算在...UDP协议全称是用户数据报协议,在网络中它与TCP协议一样用于处理数据包,是一种无连接的协议.在OSI中,第四层传输层,处于IP协议的上一层UDP

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 19,988
精华内容 7,995
关键字:

复位tcp协议