tcp协议 订阅
传输控制协议(TCP,Transmission Control Protocol)是一种面向连接的、可靠的、基于字节流的传输层通信协议,由IETF的RFC 793 [1]  定义。TCP旨在适应支持多网络应用的分层协议层次结构。 连接到不同但互连的计算机通信网络的主计算机中的成对进程之间依靠TCP提供可靠的通信服务。TCP假设它可以从较低级别的协议获得简单的,可能不可靠的数据报服务。 原则上,TCP应该能够在从硬线连接到分组交换或电路交换网络的各种通信系统之上操作。 展开全文
传输控制协议(TCP,Transmission Control Protocol)是一种面向连接的、可靠的、基于字节流的传输层通信协议,由IETF的RFC 793 [1]  定义。TCP旨在适应支持多网络应用的分层协议层次结构。 连接到不同但互连的计算机通信网络的主计算机中的成对进程之间依靠TCP提供可靠的通信服务。TCP假设它可以从较低级别的协议获得简单的,可能不可靠的数据报服务。 原则上,TCP应该能够在从硬线连接到分组交换或电路交换网络的各种通信系统之上操作。
信息
工    作
与IP协议共同使用
外文名
Transmission Control Protocol
数据格式
字节流
中文名
传输控制协议
应用层次
传输层
服    务
由套接字端点获得
TCP简介
传输控制协议(TCP,Transmission Control Protocol)是为了在不可靠的互联网络上提供可靠的端到端字节流而专门设计的一个传输协议。 [2]  互联网络与单个网络有很大的不同,因为互联网络的不同部分可能有截然不同的拓扑结构、带宽、延迟、数据包大小和其他参数。TCP的设计目标是能够动态地适应互联网络的这些特性,而且具备面对各种故障时的健壮性。 [2]  不同主机的应用层之间经常需要可靠的、像管道一样的连接,但是IP层不提供这样的流机制,而是提供不可靠的包交换。 [3]  应用层向TCP层发送用于网间传输的、用8位字节表示的数据流,然后TCP把数据流分区成适当长度的报文段(通常受该计算机连接的网络的数据链路层的最大传输单元(MTU)的限制)。之后TCP把结果包传给IP层,由它来通过网络将包传送给接收端实体的TCP层。TCP为了保证不发生丢包,就给每个包一个序号,同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的包发回一个相应的确认(ACK);如果发送端实体在合理的往返时延(RTT)内未收到确认,那么对应的数据包就被假设为已丢失将会被进行重传。TCP用一个校验和函数来检验数据是否有错误;在发送和接收时都要计算校验和。 [3]  每台支持TCP的机器都有一个TCP传输实体。TCP实体可以是一个库过程、一个用户进程,或者内核的一部分。在所有这些情形下,它管理TCP流,以及与IP层之间的接口。TCP传输实体接受本地进程的用户数据流,将它们分割成不超过64KB(实际上去掉IP和TCP头,通常不超过1460数据字节)的分段,每个分段以单独的IP数据报形式发送。当包含TCP数据的数据报到达一台机器时,它们被递交给TCP传输实体,TCP传输实体重构出原始的字节流。为简化起见,我们有时候仅仅用“TCP”来代表TCP传输实体(一段软件)或者TCP协议(一组规则)。根据上下文语义你应该能很消楚地推断出其实际含义。例如,在“用户将数据交给TCP”这句话中,很显然这里指的是TCP传输实体。 [2]  IP层并不保证数据报一定被正确地递交到接收方,也不指示数据报的发送速度有多快。正是TCP负责既要足够快地发送数据报,以便使用网络容量,但又不能引起网络拥塞:而且,TCP超时后,要重传没有递交的数据报。即使被正确递交的数据报,也可能存在错序的问题,这也是TCP的责任,它必须把接收到的数据报重新装配成正确的顺序。简而言之,TCP必须提供可靠性的良好性能,这正是大多数用户所期望的而IP又没有提供的功能。 [2] 
收起全文
精华内容
下载资源
问答
  • tcp协议
    千次阅读
    2022-04-10 23:22:21

    一.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协议和UDP协议

    万次阅读 多人点赞 2022-02-18 13:30:13
    1.传输控制协议TCP 1.1TCP的主要特点: 1.1.1面向连接的运输层协议 socket部分讲述 tcp连接的建立 tcp连接的释放 tcp的有限状态机 1.1.2每一条TCP连接只能有两个端点,每一条TCP链接只能是点对点的(一对一)...

    (注:本文部分摘自《计算机网络 谢希仁》)

    目录

    1.传输控制协议TCP

    1.1TCP的主要特点:

    1.1.1面向连接的运输层协议

    1.1.2每一条TCP连接只能有两个端点,每一条TCP链接只能是点对点的(一对一)

    1.1.3TCP提供可靠交付的服务

    1.1.4TCP提供全双工通信

    1.1.5面向字节流

    1.2与TCP有关的面试问题

    2.用户数据报协议UDP

    2.1UDP协议的主要特点:


     

    1.传输控制协议TCP

    1.1TCP的主要特点:

    1.1.1面向连接的运输层协议

    (1)TCP的连接

    TCP的许多特性都与TCP是面向连接的这个基本特性有关,因此要对TCP的连接有更清楚的了解。

    每一条TCP连接唯一地被通信两端的两个端点所确定,所谓的端点就是套接字(或插口)。

    套接字的表示方法:在点分十进制的IP地址后面写上端口号,例如IP地址是192.3.4.5,端口号是80,那么套接字就是(192.3.4.5:80) 。

    (2)TCP的连接建立

    三次握手:TCP建立连接的过程叫做握手,握手需要在客户端和服务器之间交换三个TCP报文段。此过程如下:

    watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5Luf5ZCE,size_20,color_FFFFFF,t_70,g_se,x_16

    (3)tcp的连接释放

     四次挥手过程如下:

    watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5Luf5ZCE,size_20,color_FFFFFF,t_70,g_se,x_16

    (4)tcp的有限状态机

    可以看我之前的这篇文章,这里不再赘述。

    TCP连接的状态——TIME_WAIT的存在意义https://blog.csdn.net/m0_54355780/article/details/121190546

    1.1.2每一条TCP连接只能有两个端点,每一条TCP链接只能是点对点的(一对一)

    1.1.3TCP提供可靠交付的服务

    (1)可靠传输的工作原理

    ①停止等待协议:

    “停止等待”就是每发送完一个分组就停止发送,等待对方确认。在收到确认后再发送下一个分组。

    • 无差错的情况下:一端发送,另一端等待并接收
    • 出现差错的情况:一端在一段时间(会设置有超时计时器)一直没有收到确认,认为自己刚发送的内容丢失,于是重新发送,这就叫超时重传。这里需要注意三点:第一,发送完自己的分组需暂时保留自己的副本,以防超时重传;第二,分组和确认分组要编号,从而确认哪些分组收到确认,哪些分组没有收到确认;第三,超时计时器设置的重传时间应当比数据在分组传输的平均往返时间长一些。
    • 确认丢失和确认迟到:  watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5Luf5ZCE,size_20,color_FFFFFF,t_70,g_se,x_16
    • 信道利用率 

    3f1858d7441447c78a9f8c6eebc5714a.png

    等值等待协议的信道利用情况如下图:

     

    watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5Luf5ZCE,size_20,color_FFFFFF,t_70,g_se,x_16

    为了提高效率,发送方可以不使用低效率的停止等待协议,使用流水线传输,流水线传输就是发送方可以连续发送多个分组,不必每发完一个分组就停下来等待对方的确认。

    watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5Luf5ZCE,size_20,color_FFFFFF,t_70,g_se,x_16

    ②连续的ARQ协议

    连续ARQ协议规定:发送方每收到一个确认,就把发送窗口向前滑动一个分组的位置。接收方采用累计确认的方式,也就是说:接收方不必对收到分组逐个发送确认,而是在收到几个分组之后,对按序到达的最后一个分组发送确认。

    (2)可靠传输的实现

    ①超时重传时间的选择

    报文段的往返时间RTT:采用自适应算法,记录一个报文段发出的时间,以及收到相应确认的时间。这两个时间之差就是RTT。

    平滑的往返事件RTTs:RTT的一个加权平均往返时间

    watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5Luf5ZCE,size_20,color_FFFFFF,t_70,g_se,x_16

    上式的α值在RFC 6298推荐为0.125 。

    超时重传时间RTO:报文每重传一次,就把超时重传时间RTO增大一些,取新的重传时间为旧的重传时间的2倍。当不再发生报文段的重传时,才根据下面的式子计算超时重传时间。

    watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5Luf5ZCE,size_20,color_FFFFFF,t_70,g_se,x_16

    ②选择确认SACK

    如果收到的报文没有差错,但是未按序号,中间还缺少一些数据,使用选择确认可以只传送缺少的数据而不重传已经确认到达接收方的数据。

    要使用选择确认,需在TCP首部的选项中加上“允许SACK”的选项,并且双方必须事先商定好。

    但是首部最长40字节,如果要报告5个字节块的边界信息,那么5个边界需要2*5*4=40个字节来表述,再加上一个字节指明SACK选项命令一个字节指明SACK占用多少字节,这就一共需要42字节,超出首部长度。因此大多数的实现还是需要重传全部的数据块。

    ③流量控制

    流量控制的目的:让发送方的发送速率不要太快,从而让接收方来的及接收

    • 滑动窗口:在 TCP 的报头中有一个字段叫做接收通告窗口,这个字段由接收端填充,是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据,而不会导致接收端处理不过来。所以发送端就会有一个发送窗口,这个发送窗 口的大小是由接收端填充的接收通告窗口的大小决定的,并且窗口的位置会随着发送端数据 的发送和接收到接收端对数据的确认而不断的向右滑动,将之称为滑动窗口。(TCP的滑动窗口以字节为单位)watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5Luf5ZCE,size_20,color_FFFFFF,t_70,g_se,x_16p3-p1=A的发送窗口;p2-p1=已发送但尚未收到确认的字节数;p3-p2=允许发送但尚未发送的字节数。此外,需要注意的是,并不是发送方将数据直接发给接收方,而是发送方的应用进程把字节流写入TCP的发送缓存,发送缓存用来暂时存放发送应用程序传送给发送方TCP准备发送的数据以及TCP已发送出但尚未收到确认的数据。接收方的应用进程从TCP的接收缓存中读取字节流,接收缓存用来暂时存放按序到达但尚未被接收应用程序读取的数据以及为按序到达的数据。最后在滑动窗口的部分知识中需要注意三点:第一,同一时刻,发送方的发送端口并不总是和接收方的接收窗口一样大,其会根据网络拥塞情况适当减少自己的窗口值;第二,不按序到达的数据,先临时存放在接收缓存中,等到缺少的字节收到后,再按序交付给上层的应用进程;第三,TCP接收方要有累计确认的功能。
    • TCP的传输效率:TCP报文段的发送时机有三个控制机制:第一种,缓存中存放数据达到MSS(最大报文段长度)字节时,就组装成一个TCP报文段发送;第二种,发送方应用进程指明要求发送报文段;第三种,发送方的一个计时期限到了,就把当前已有 缓存数据并且<=MSS装入报文段发送出去。

    ④拥塞控制

    • 满开始:由小到大逐渐增大拥塞窗口数值。
    • 拥塞避免:为了防止拥塞窗口增长过大引起网络拥塞,设置慢开始门限。然后拥塞避免的算法思路就是让拥塞窗口缓慢增大,即每经过一个往返时间RTT就把发送方的拥塞窗口加一。
    • 快速重传:接收方不要等待中积极发送数据的时候再进行对之前数据的捎带确认,而是收到数据立即发送确认。快重传算法规定:发送方一连收到三个重复的确认,就应当进行快重传。
    • 快速恢复:当出现超时的时候,不启动慢开始,而是执行快恢复算法。发送方调整门限值=出现超时的cwnd(拥塞窗口)/2。watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5Luf5ZCE,size_20,color_FFFFFF,t_70,g_se,x_16

     

    1.1.4TCP提供全双工通信

    1.1.5面向字节流

    流式服务的特点:TCP 字节流的特点,发送端执行的写操作次数和接收端执行的读操作次数之间没有任何数量关系,应用程序对数据的发送和接收是没有边界限制的。

    1.2与TCP有关的面试问题

    (1)为什么时三次握手,可不可以是两次握手,为什么?

    如果是两次握手,那么如果出现这种情况:发送端发送请求连接报文,但是由于在网络中出现了滞留并没有按时到达接收端,等到一段时间发送端再次发送连接请求报文,接收端接收之后并发送确认连接。这样两次握手建立连接1。但是之前在网络中滞留的连接请求报文并没有丢失,于是发送给接收端,接收端误以为建立连接,于是就回复确认建立连接,所以此时又建立了连接2,但是发送端并不会给连接2发送数据,所以接收端一直处于等待,就会浪费接受端许多资源。

    三次握手也可以是四次握手:接收端在回复确认建立连接报文的时候,将其分成两个报文段,一个是回复对发送端的连接确认,一个是发送自己的同步报文段。

    (2)三次握手时可能出现什么攻击?

    可以参考下面这篇文章:

    TCP三次握手有哪些漏洞?https://www.cnblogs.com/HuiH/p/12599048.html可能出现的攻击有三种:SYN flood的攻击,TCP全连接攻击,Land攻击。

    (3)四次挥手的过程可以用三次完成吗?

    关闭连接时,服务器端收到FIN报文,并不会立刻关闭SOCKET,先回复ACK报文,等到服务器端的所有报文都发送完了,才发送FIN报文。所以不能三次完成,将ACK和FIN不能放在一起发送。

    (4)对于三次握手四次挥手的面试题,可以看看这个文章

    面试官,不要再问我三次握手和四次挥手https://zhuanlan.zhihu.com/p/86426969

    (5)同一个端口可不可以被一个 TCP 和一个 UDP 的应用程序同时使用?

    可以。原因是端口的唯一性标识是:端口号+协议名称。所以TCP和UDP的端口完全没有任何关系,协议内部端口号唯一。

    追问:程序在连接到端口时,怎么知道此时从该端口进来的数据是tcp的还是udp的呢?

    操作系统根据接收的IP数据包的首部内的8位协议来判断这是什么报文,从而直接交给相关的内核进程或者协议栈处理。

    追问:一个端口是否可以绑定多个端口号?

    可以。一个进程可以打开多个文件描述符,每个文件描述符对应一个端口号,所以一个进程可以绑定多个端口号。Linux会给每个socket分配一个唯一的文件描述符,通过这个文件描述符来区分对应的套接字。

    追问:一个端口号是否可以被多个进程绑定?

    不可以。但是在父子进程中可以实现多进程绑定一个端口号,因为子进程具有父进程的文件描述符副本,可以处理绑定到同样的端口上的连接

    追问:一个端口可以同时连接多个TCP和多个UDP吗?

    一个端口可以建立多个TCP连接,所谓的同一个端口是指服务器端的ip和port不变,但是只要客户端的ip和port不同就可以。一个端口同一时间只能绑定一个socket。UDP是面向无连接的,所以不存在多个UDP连接,只是服务端接收UDP数据需要绑定一个端口,一个socket只能绑定一个端口而已。

    (如果还不是很清楚这方面的问题,可以参考下面几篇文章)

    TCP和UDP使用同一端口通信https://blog.csdn.net/szm1234/article/details/116994450一个端口号可以同时被两个进程绑定吗?https://zhuanlan.zhihu.com/p/280672302#:~:text= 由上述结果可知:TCP、UDP可以同时绑定一个端口8888,但是一个端口在同一时刻不可以被TCP或者UDP绑定2次。,原因如下: TCP和UDP传输协议监听同一个端口后,接收数据互不影响,不冲突。快狗二面 一个端口可以 同时TCP 又UDP 吗?https://cloud.tencent.com/developer/article/1813256

    (6)同一个应用程序可以创建多个套接字吗?

    端口是唯一的,系统中任一个端口只能被一个程序占用。一个程序可以创建多个Socket,但多个Socket是不能共用端口的。

    (7)什么是 TCP 粘包,如何解决?

    定义:指的是多个报文数据内容融合在一起被接受

    解决方案:

    ①循环接收、发送;即就是一次send,一次recv……

    ②设置分割标志。

    ③在头部加上长度控制,然后读取的时候只读取头部信息中指定的长度。

    (8)为什么UDP数据包不发生粘包,而TCP会出现粘包?

    TCP协议是面向链接的,收发两端都必须要有成对的socket,因此发送端为了将多个发往接收端的包更有效的发送,使用了优化的方法nagle算法。

    面向流的服务是没有消息保护边界的。

    UDP协议是无连接,面向消息的,支持一对多的模式,所以接收端的套接字缓冲区采用链式结构记录每一个到达的UDP包。

    面向消息的通信是由消息保护边界的。

    (9)如果接收端填充的接收通告窗口为 0,发送端接下来怎么处理?

    接收端通告的窗口大小变成0,发送端会发一个1字节的段,这一个字节段可以是下一字节的数据,如果没有新的数据段发送的时候,就发一个ack,强制接收端重新宣告下一个期望的字节和窗口大小。如果接收方回复窗口大小仍然为零,则发送方的探测定时器加倍。没有收到ACK时,发送探测包的最大次数之后连接超时。

    (10)什么叫糊涂窗口综合征?

    糊涂窗口综合症是指当发送端应用进程产生数据很慢、或接收端应用进程处理接收缓冲区数据很慢,或二者兼而有之;就会使应用进程间传送的报文段很小,特别是有效载荷很小; 极端情况下,有效载荷可能只有1个字节;传输开销有40字节(20字节的IP头+20字节的TCP头) 这种现象。

    要解决这个问题,发送方要把数据累计成足够大的报文段,等到其到达接收方缓存区的一半大小,再发送报文。接收方等待一段时间,使得自己的接收缓存区中能够容纳一个最长的报文段或缓存区有一半空闲,然后再去发送确认报文。

    (11)在 TCP 的实现中广泛使用的 Nagle 算法是什么?

    若发送应用进程,把要发送的数据逐个字节的送到TCP的发送缓存,则发送方就把第一个数据字节先发送出去,把后面的数据字节都缓存起来。当发送方收到对第一个数据字符的确认后,再把发送缓存中的所有数据组装成一个发送报文段发送出去。

    (12)TIME_WAIT 状态存在的原因?

    ①保证发送端发送的最后一个ACK报文段能够到达接收端,从而避免接收端因为收不到ACK报文段而不按照正常步骤进入CLOSED状态。

    ②使本链接持续的时间内所产生的所有报文都从网络中消失,避免下一个新连接中出现旧的连接请求报文段。

    2.用户数据报协议UDP

    2.1UDP协议的主要特点:

    (1)UDP是无连接的,可以减少开销和发送数据之前的时延。

    (2)UDP使用尽最大努力交付,不保证可靠交付,主机不需要维持复杂的连接状态表。

    (3)UDP是面向报文的,一次交付一个完整的报文。

    (4)UDP没有拥塞控制,因此网络出现的拥塞不会使得源主机的发送速率降低。

    (5)UDP支持一对一、一对多、多对一、多对多的交互通信。

    (6)UDP的首部开销小,只有八字节。

     

     

     

    展开全文
  • 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协议】TCP 协议和 UDP 协议的优势和劣势 文章目录【TCP协议】TCP 协议和 UDP 协议的优势和劣势一、UDP 协议UDP 的封包格式校验和(Checksum)机制二、UDP 与 TCP的区别1.目的差异2.可靠性差异3.连接 vs 无连接4...
  • UDP协议和TCP协议

    万次阅读 2022-02-19 21:22:31
    TCP对比:不可靠、无连接、面向报文 1. 网络的基本情况就是不可靠的 没有谁能保证数据一定是可以发送到对方的,可能丢失(丢包) 即使数据发送给对方了,也不能保证数据就是无差错的(不考虑有人故意修改数据的...
  • TCP协议与IP协议

    千次阅读 2022-03-02 15:11:20
    TCP协议与IP协议是目前互联网中运用的最常见的网络协议,它们事实上是一些协议(protocols)的合集,当前大多数通信中都使用TCP协议。Internet在一些共享线路上发送数据,计算机上可以同时运行多个应用程而只需通过...
  • TCP 协议(包含三次握手,四次挥手)

    万次阅读 多人点赞 2022-01-04 18:08:48
    TCP 特性1.确认应答 (可靠传输的最核心机制) 1.确认应答 (可靠传输的最核心机制) 可靠传输的最核心机制
  • TCP协议详解 (史上最全)

    万次阅读 多人点赞 2021-03-08 12:27:36
    传输层TCP协议提供了一种面向连接的、可靠的字节流服务,其数据帧格式,大致如下图所示: 图:传输层TCP协议的数据帧格式 一个传输层TCP协议的数据帧,大致包含以下字段: (一)源端口号 源端口号表示报文的发送...
  • TCP协议是什么,TCP协议适用场景

    千次阅读 2022-01-25 10:08:16
    TCP协议的特点: 1.TCP协议是一种面向连接的,可靠的字节流服务。在进行数据传输之前必须建立连接,就比如打电话,只有在对方接通后才能开始对话。建立连接的方法是“三次握手”。 2.可靠性高。在TCP的
  • tcp协议的主要功能_tcp协议的特点

    千次阅读 2021-06-28 04:02:35
    传输控制协议(TCP,TransmissionControlProtocol)是一种面向连接的、可靠的、基于字节流的传输层通信协议,由IETF的RFC793定义。TCP旨在适应支持多网络应用的分层协议层次结构。连接到不同但互连的计算机通信网络的...
  • 计算机网络面试——TCP协议

    千次阅读 2022-03-18 14:12:10
    TCP协议是传输层的协议,为应用层协议协议提供了安全保障工作,下面我们将详细了解一下TCP协议。 二、TCP协议详解 1、TCP协议TCP协议又称传输控制协议。 2、TCP报文的组成 3、TCP协议的特点: 3.1、TCP是面向连接...
  • TCP 协议报文格式

    千次阅读 多人点赞 2022-01-03 13:06:21
    前面,我们已经提过TCP 协议属于传输层协议,以及TCP/IP 五层/四层模型 数据从应用层开始,会在每一层都会加上头信息,进行封装,再发送到数据接收端 TCP 协议报文格式端口号序列号确认号数据偏移字段保留字段标志位...
  • TCP协议如何保证可靠传输

    千次阅读 多人点赞 2021-11-19 23:26:38
    本文介绍TCP协议如何保证可靠传输。 本内容也是Java后端面试常见的问题。 概述 TCP协议保证数据传输可靠性的方式主要有: 大小控制 应用数据被分割成 TCP 认为最适合发送的数据块。 序列号 TCP 给发送的每一个包...
  • 剖析 TCP协议内部结构

    千次阅读 2022-03-17 08:41:22
    1、TCP协议 2、组成结构分析 1、源端口号:发送方端口号 2、目的端口号:接收方端口号 3、序列号:报文段的数据的第一个字节的序号 3、确认序号:期望收到对方下一个报文段的第一个数据字节的序号 4、首部长度(数据...
  • 什么是TCP协议

    千次阅读 2022-03-11 17:17:45
    TCP,传输控制协议(Transmission Control Protocol)是为了在不可靠的互联网络上提供可靠的端到端字节流而专门设计的一个传输协议。一般是用于网页端。 TCP的主要功能: 1.慢启动 每当建立一个TCP连接时或一个...
  • TCP协议与UDP协议的区别

    千次阅读 2021-09-14 23:01:25
    TCP协议与UDP协议的区别 TCP/IP协议是一个协议簇。里面包括很多协议的,UDP只是其中的一个, 之所以命名为TCP/IP协议,因为TCP、IP协议是两个很重要的协议,就用他两命名了。 TCP/IP协议集包括应用层,传输层,网络层...
  • ModBusTcp协议(一)

    千次阅读 2022-04-14 19:42:17
    ModBusTcp协议 简介 Modbus由MODICON公司于1979年开发,是一种工业现场总线协议标准。1996年施耐德公司推出基于以太网TCP/IP的Modbus协议:ModbusTCP。 Modbus协议是一项应用层报文传输协议,包括ASCII、RTU、...
  • 什么是TCP协议?

    千次阅读 2021-08-08 09:51:00
    什么是TCP协议TCP协议是传输控制协议,位于应用程序层和网络层之间,用于提供可靠的流传递服务,即以字节流的形式传递数据,也以字节流的形式接收数据。TCP使用确认机制检查数据的安全和声音到达,在发送方执行多...
  • python写TCP协议

    千次阅读 2022-03-02 17:00:08
    才能在connect里面连接上 clientSocket = socket(AF_INET, SOCK_STREAM) # 第一个参数意思是这是ipv4的地址,第二个参数意思是我用的是TCP协议 clientSocket.connect((host_name, port_num)) # 把ip和端口放到元组...
  • TCP协议与UDP协议(学习笔记)

    千次阅读 2022-03-13 09:48:44
    对于TCP协议和UDP协议,大家应该都有所耳闻。我们常用的网络通讯,比如浏览网页、软件聊天、收看视频都是通过这两种协议来进行数据传输。到底他们是如何工作的?这两种协议有什么区别?本文将进行初步讲解。 TCP协议...
  • TCP 协议

    千次阅读 2022-03-17 16:42:24
    TCP 协议是一种面向连接的、可靠的、基于字节流的传输层通信协议TCP 是为了在不可靠的互联网络上提供可靠的端到端字节流而专门设计的一个传输协议。 应用层向TCP层发送用于网间传输的、用8位字节表示的数据流,...
  • 【python】TCP协议编程

    千次阅读 2022-04-16 20:51:35
    TCP协议适用于对效率要求相对较低而准确性要求很高的场合,例如文件传输、电子邮件等等,需要建立连接、数据传输、断开连接三个步骤。 例:TCP通信程序。模拟机器人聊天软件原理,服务端提前建立好字典,然后根据...
  • Nginx与TCP协议的关系

    千次阅读 2022-04-09 14:26:26
    作为Web服务器的nginx,主要任务当然是处理好基于TCP的HTTP协议,本节将深入TCP协议的实现细节(linux下)以更好地理解Nginx事件处理机制。 TCP是一个面向连接的协议,它必须基于建立好的TCP连接来为通信的两方提供...
  • [计算机网络] 实验四 TCP协议分析

    千次阅读 2022-05-10 22:15:25
    了解运输层 TCP 协议基本概念、报文结构 分析 TCP 报文头部 分析 TCP 连接建立过程、TCP 连接释放 掌握利用 tcpdump 和 wireshark 进行 tcp 协议分析技术。 实验内容 1.wget使用和TCP分析 [如果你还不懂...
  • 详解TCP协议三次握手四次挥手

    万次阅读 2022-02-13 21:23:29
    详解TCP协议三次握手四次挥手
  • 网络通讯之TCP协议实用案例

    千次阅读 2021-12-30 21:23:48
    文章目录前言一、TCP协议是什么?二、Qt中实现TCP网络通信流程1.创建两个类2.TCP通信过程三、代码讲解1、服务器端cpp文件代码2、客户端cpp文件代码四、程序演示 前言 在日常IT领域内,socket网络编程是非常重要的...
  • TCP协议】TCP 为什么握手是 3 次、挥手是 4 次? 文章目录【TCP协议】TCP 为什么握手是 3 次、挥手是 4 次?TCP 协议① 主机到主机(Host-To-Host)② 相关概念解释会话是应用层的概念,连接是传输层的概念③ 双工...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 863,029
精华内容 345,211
关键字:

tcp协议

友情链接: fudiaops.rar