tcp_tcpip - CSDN
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协议的可靠性传输机制

    万人学习 2019-07-01 10:40:03
    本课程是2015年10月14号晚上在CSDN学院进行的一场公开课,主讲TCP协议的几个方面的传输机制,主要包括以下几个方面: TCP数据段结构及主要特性 TCP数据段的可靠传输机制 TCP数据段的可靠接收机制 TCP数据段的...
  • 一文搞懂什么是TCP/IP协议

    万次阅读 多人点赞 2020-05-06 15:41:03
    什么是TCP/IP协议? 计算机与网络设备之间如果要相互通信,双方就必须基于相同的方法.比如如何探测到通信目标.由哪一边先发起通信,使用哪种语言进行通信,怎样结束通信等规则都需要事先确定.不同的硬件,操作系统之间的...

    什么是TCP/IP协议?

    计算机与网络设备之间如果要相互通信,双方就必须基于相同的方法.比如如何探测到通信目标.由哪一边先发起通信,使用哪种语言进行通信,怎样结束通信等规则都需要事先确定.不同的硬件,操作系统之间的通信,所有这一切都需要一种规则.而我们就将这种规则称为协议 (protocol).

    image-20191027150025587

    也就是说,TCP/IP 是互联网相关各类协议族的总称。

    TCP/IP 的分层管理

    TCP/IP协议里最重要的一点就是分层。TCP/IP协议族按层次分别为 应用层,传输层,网络层,数据链路层,物理层。当然也有按不同的模型分为4层或者7层的。

    为什么要分层呢?

    把 TCP/IP 协议分层之后,如果后期某个地方设计修改,那么就无需全部替换,只需要将变动的层替换。而且从设计上来说,也变得简单了。处于应用层上的应用可以只考虑分派给自己的任务,而不需要弄清对方在地球上哪个地方,怎样传输,如果确保到达率等问题。

    image-20191027150352733

    如上图所示,我们将TCP/IP分为5层,越靠下越接近硬件。我们由下到上来了解一下这些分层。

    1. 物理层

      该层负责 比特流在节点之间的传输,即负责物理传输,这一层的协议既与链路有关,也与传输的介质有关。通俗来说就是把计算机连接起来的物理手段。

    2. 数据链路层

      控制网络层与物理层之间的通信,主要功能是保证物理线路上进行可靠的数据传递。为了保证传输,从网络层接收到的数据被分割成特定的可被物理层传输的帧。帧是用来移动数据结构的结构包,他不仅包含原始数据,还包含发送方和接收方的物理地址以及纠错和控制信息。其中的地址确定了帧将发送到何处,而纠错和控制信息则确保帧无差错到达。如果在传达数据时,接收点检测到所传数据中有差错,就要通知发送方重发这一帧。

    3. 网络层

      决定如何将数据从发送方路由到接收方。网络层通过综合考虑发送优先权,网络拥塞程度,服务质量以及可选路由的花费等来决定从网络中的A节点到B节点的最佳途径。即建立主机到主机的通信。

    4. 传输层

      该层为两台主机上的应用程序提供端到端的通信。传输层有两个传输协议:TCP(传输控制协议)和 UDP(用户数据报协议)。其中,TCP是一个可靠的面向连接的协议,udp是不可靠的或者说无连接的协议

    5. 应用层

      应用程序收到传输层的数据后,接下来就要进行解读。解读必须事先规定好格式,而应用层就是规定应用程序的数据格式。主要的协议有:HTTP.FTP,Telent等。

    TCP与UDP

    TCP/UDP 都是传输层协议,但是两者具有不同的特效,同时也具有不同的应用场景。

    image-20191027212512703

    面向报文

    面向报文的传输方式是应用层交给UDP多长的报文,UDP发送多长的报文,即一次发送一个报文。因此,应用程序必须选择合适大小的报文。

    面向字节流

    虽然应用程序和TCP的交互是一次一个数据块(大小不等),但TCP把应用程序看成是一连串的无结构的字节流。TCP有一个缓冲,当应该程序传送的数据块太长,TCP就可以把它划分短一些再传送。

    TCP的三次握手与四次挥手

    具体过程如下:

    • 第一次握手:建立连接。客户端发送连接请求报文段,并将syn(标记位)设置为1,Squence Number(数据包序号)(seq)为x,接下来等待服务端确认,客户端进入SYN_SENT状态(请求连接);

    • 第二次握手:服务端收到客户端的 SYN 报文段,对 SYN 报文段进行确认,设置 ack(确认号)为 x+1(即seq+1 ; 同时自己还要发送 SYN 请求信息,将 SYN 设置为1, seq为 y。服务端将上述所有信息放到 SYN+ACK 报文段中,一并发送给客户端,此时服务器进入 SYN_RECV状态。

      SYN_RECV是指,服务端被动打开后,接收到了客户端的SYN并且发送了ACK时的状态。再进一步接收到客户端的ACK就进入ESTABLISHED状态。

    • 第三次握手:客户端收到服务端的 SYN+ACK(确认符) 报文段;然后将 ACK 设置为 y+1,向服务端发送ACK报文段,这个报文段发送完毕后,客户端和服务端都进入ESTABLISHED(连接成功)状态,完成TCP 的三次握手。

    上面的解释可能有点不好理解,用《图解HTTP》中的一副插图 帮助大家。

    img

    当客户端和服务端通过三次握手建立了 TCP 连接以后,当数据传送完毕,断开连接就需要进行TCP的四次挥手。其四次挥手如下所示:

    • 第一次挥手

      客户端设置seq和 ACK ,向服务器发送一个 FIN(终结)报文段。此时,客户端进入 FIN_WAIT_1 状态,表示客户端没有数据要发送给服务端了。

    • 第二次挥手

      服务端收到了客户端发送的 FIN 报文段,向客户端回了一个 ACK 报文段。

    • 第三次挥手

      服务端向客户端发送FIN 报文段,请求关闭连接,同时服务端进入 LAST_ACK 状态。

    • 第四次挥手

      客户端收到服务端发送的 FIN 报文段后,向服务端发送 ACK 报文段,然后客户端进入 TIME_WAIT 状态。服务端收到客户端的 ACK 报文段以后,就关闭连接。此时,客户端等待 2MSL(指一个片段在网络中最大的存活时间)后依然没有收到回复,则说明服务端已经正常关闭,这样客户端就可以关闭连接了。

    最后再看一下完整的过程:

    img

    如果有大量的连接,每次在连接,关闭都要经历三次握手,四次挥手,这显然会造成性能低下。因此。Http 有一种叫做 长连接(keepalive connections) 的机制。它可以在传输数据后仍保持连接,当客户端需要再次获取数据时,直接使用刚刚空闲下来的连接而无需再次握手。

    img

    一些问题汇总:

    1. 为什么要三次握手?

    为了防止已失效的连接请求报文突然又传送到了服务端,因为产生错误。

    具体解释: “已失效的连接请求报文段”产生情况:

    client 发出的第一个连接请求报文段并没有丢失,而是在某个网络节点长时间滞留,因此导致延误到连接释放以后的某个时间才到达 service。如果没有三次握手,那么此时server收到此失效的连接请求报文段,就误认为是 client再次发出的一个新的连接请求,于是向 client 发出确认报文段,同意建立连接,而此时 client 并没有发出建立连接的情况,因此并不会理会服务端的响应,而service将会一直等待client发送数据,因此就会导致这条连接线路白白浪费。

    如果此时变成两次挥手行不行?

    这个时候需要明白全双工与半双工,再进行回答。比如:

    • 第一次握手: A给B打电话说,你可以听到我说话吗?
    • 第二次握手: B收到了A的信息,然后对A说: 我可以听得到你说话啊,你能听得到我说话吗?
    • 第三次握手: A收到了B的信息,然后说可以的,我要给你发信息啦!

    在三次握手之后,A和B都能确定这么一件事: 我说的话,你能听到; 你说的话,我也能听到。 这样,就可以开始正常通信了,如果是两次,那将无法确定。

    2. 为什么要四次挥手?

    TCP 协议是一种面向连接,可靠,基于字节流的传输层通信协议。TCP 是全双工模式(同一时刻可以同时发送和接收),这就意味着,当主机1发出 FIN 报文段时,只是表示主机1已结没有数据要发送了,主机1告诉主机2,它的数据已经全部发送完毕;但是,这个时候主机1还是可以接受来自主机2的数据;当主机2返回 ACK报文段时,这个时候就表示主机2也没有数据要发送了,就会告诉主机1,我也没有数据要发送了,之后彼此就会中断这次TCP连接。

    3.为什么要等待 2MSL

    MSL:报文段最大生存时间,它是任何报文段被丢弃前在网络内的最长时间

    原因如下:

    • 保证TCP协议的全双工连接能够可靠关闭
    • 保证这次连接的重复数据从网络中消息

    第一点: 如果主机1直接 关闭,由于IP协议的不可靠性或者其他网络原因,导致主机2没有收到主机1最后回复的 ACK。那么主机2就会在超时之后继续发送 FIN,此时由于主机1已经关闭,就找不到与重发的 FIN 对应的连接。所以,主机1 不是直接进入 关闭,而是TIME_WAIT 状态。当再次收到 FIN 的时候,能够保证对方收到 ACK ,最后正确关闭连接。

    第二点:如果主机1直接 关闭,然后又再向主机 2 发起一个新连接,我们不能保证这个新连接与刚才关闭的连接端口是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题,但还是有特殊情况出现;假设新连接和已经关闭的老连接端口号是一样的,如果前一次连接的某些数据仍然滞留在网络中( Lost Duplicate ),那些延迟数据在建立新连接之后才到达主机2,由于新连接和老连接的端口号是一样的,TCP 协议就认为哪个延迟的数据时属于新连接的,这样就和真正的新连接的数据包发生混淆了。所以TCP连接要在 TIME_WAIT 状态等待两倍 MSL ,保证本次连接的所有数据都从网络中消失。




    参考内容

    <图解HTTP>
    <Android进阶之光-网络篇>
    知乎-TCP 为什么是三次握手,而不是两次或四次?

    展开全文
  • TCP 详解

    万次阅读 多人点赞 2018-06-20 00:30:57
    上回说到 UDP 协议, 与之对应的便是 TCP 协议 TCP协议 TCP协议全称: 传输控制协议, 顾名思义, 就是要对数据的传输进行一定的控制. 先来看看它的报头 我们来分析分析每部分的含义和作用 源端口号/目的端口号:...

    上回说到 UDP 协议, 与之对应的便是 TCP 协议

    TCP协议

    TCP协议全称: 传输控制协议, 顾名思义, 就是要对数据的传输进行一定的控制.
    先来看看它的报头
    Alt text

    我们来分析分析每部分的含义和作用

    • 源端口号/目的端口号: 表示数据从哪个进程来, 到哪个进程去.
    • 32位序号:
    • 4位首部长度: 表示该tcp报头有多少个4字节(32个bit)
    • 6位保留: 顾名思义, 先保留着, 以防万一
    • 6位标志位

      URG: 标识紧急指针是否有效
      ACK: 标识确认序号是否有效
      PSH: 用来提示接收端应用程序立刻将数据从tcp缓冲区读走
      RST: 要求重新建立连接. 我们把含有RST标识的报文称为复位报文段
      SYN: 请求建立连接. 我们把含有SYN标识的报文称为同步报文段
      FIN: 通知对端, 本端即将关闭. 我们把含有FIN标识的报文称为结束报文段

    • 16位窗口大小:

    • 16位检验和: 由发送端填充, 检验形式有CRC校验等. 如果接收端校验不通过, 则认为数据有问题. 此处的校验和不光包含TCP首部, 也包含TCP数据部分.
    • 16位紧急指针: 用来标识哪部分数据是紧急数据.
    • 选项和数据暂时忽略

    连接管理机制

    正常情况下, tcp需要经过三次握手建立连接, 四次挥手断开连接.

    那么什么是三次握手? 什么是四次挥手呢?

    三次握手

    第一次:
    客户端 - - > 服务器 此时服务器知道了客户端要建立连接了
    第二次:
    客户端 < - - 服务器 此时客户端知道服务器收到连接请求了
    第三次:
    客户端 - - > 服务器 此时服务器知道客户端收到了自己的回应

    到这里, 就可以认为客户端与服务器已经建立了连接.

    再来看个图.
    Alt text

    刚开始, 客户端和服务器都处于 CLOSE 状态.
    此时, 客户端向服务器主动发出连接请求, 服务器被动接受连接请求.

    1, TCP服务器进程先创建传输控制块TCB, 时刻准备接受客户端进程的连接请求, 此时服务器就进入了 LISTEN(监听)状态
    2, TCP客户端进程也是先创建传输控制块TCB, 然后向服务器发出连接请求报文,此时报文首部中的同步标志位SYN=1, 同时选择一个初始序列号 seq = x, 此时,TCP客户端进程进入了 SYN-SENT(同步已发送状态)状态。TCP规定, SYN报文段(SYN=1的报文段)不能携带数据,但需要消耗掉一个序号。
    3, TCP服务器收到请求报文后, 如果同意连接, 则发出确认报文。确认报文中的 ACK=1, SYN=1, 确认序号是 x+1, 同时也要为自己初始化一个序列号 seq = y, 此时, TCP服务器进程进入了SYN-RCVD(同步收到)状态。这个报文也不能携带数据, 但是同样要消耗一个序号。
    4, TCP客户端进程收到确认后还, 要向服务器给出确认。确认报文的ACK=1,确认序号是 y+1,自己的序列号是 x+1.
    5, 此时,TCP连接建立,客户端进入ESTABLISHED(已建立连接)状态。当服务器收到客户端的确认后也进入ESTABLISHED状态,此后双方就可以开始通信了。

    为什么不用两次?

    • 主要是为了防止已经失效的连接请求报文突然又传送到了服务器,从而产生错误。如果使用的是两次握手建立连接,假设有这样一种场景,客户端发送的第一个请求连接并且没有丢失,只是因为在网络中滞留的时间太长了,由于TCP的客户端迟迟没有收到确认报文,以为服务器没有收到,此时重新向服务器发送这条报文,此后客户端和服务器经过两次握手完成连接,传输数据,然后关闭连接。此时之前滞留的那一次请求连接,因为网络通畅了, 到达了服务器,这个报文本该是失效的,但是,两次握手的机制将会让客户端和服务器再次建立连接,这将导致不必要的错误和资源的费。
      如果采用的是三次握手,就算是那一次失效的报文传送过来了,服务端接受到了那条失效报文并且回复了确认报文,但是客户端不会再次发出确认。由于服务器收不到确认,就知道客户端并没有请求连接。

    为什么不用四次?

    • 因为三次已经可以满足需要了, 四次就多余了.

    再来看看何为四次挥手.

    数据传输完毕后,双方都可以释放连接.
    此时客户端和服务器都是处于ESTABLISHED状态,然后客户端主动断开连接,服务器被动断开连接.

    1, 客户端进程发出连接释放报文,并且停止发送数据。
    释放数据报文首部,FIN=1,其序列号为seq=u(等于前面已经传送过来的数据的最后一个字节的序号加1),此时客户端进入FIN-WAIT-1(终止等待1)状态。 TCP规定,FIN报文段即使不携带数据,也要消耗一个序号。
    2, 服务器收到连接释放报文,发出确认报文,ACK=1,确认序号为 u+1,并且带上自己的序列号seq=v,此时服务端就进入了CLOSE-WAIT(关闭等待)状态。
    TCP服务器通知高层的应用进程,客户端向服务器的方向就释放了,这时候处于半关闭状态,即客户端已经没有数据要发送了,但是服务器若发送数据,客户端依然要接受。这个状态还要持续一段时间,也就是整个CLOSE-WAIT状态持续的时间。
    3, 客户端收到服务器的确认请求后,此时客户端就进入FIN-WAIT-2(终止等待2)状态,等待服务器发送连接释放报文(在这之前还需要接受服务器发送的最终数据)
    4, 服务器将最后的数据发送完毕后,就向客户端发送连接释放报文,FIN=1,确认序号为v+1,由于在半关闭状态,服务器很可能又发送了一些数据,假定此时的序列号为seq=w,此时,服务器就进入了LAST-ACK(最后确认)状态,等待客户端的确认。
    5, 客户端收到服务器的连接释放报文后,必须发出确认,ACK=1,确认序号为w+1,而自己的序列号是u+1,此时,客户端就进入了TIME-WAIT(时间等待)状态。注意此时TCP连接还没有释放,必须经过2∗MSL(最长报文段寿命)的时间后,当客户端撤销相应的TCB后,才进入CLOSED状态。
    6, 服务器只要收到了客户端发出的确认,立即进入CLOSED状态。同样,撤销TCB后,就结束了这次的TCP连接。可以看到,服务器结束TCP连接的时间要比客户端早一些。

    再来看一张图.
    Alt text

    为什么最后客户端还要等待 2*MSL的时间呢?

    • MSL(Maximum Segment Lifetime),TCP允许不同的实现可以设置不同的MSL值。

    • 第一,保证客户端发送的最后一个ACK报文能够到达服务器,因为这个ACK报文可能丢失,站在服务器的角度看来,我已经发送了FIN+ACK报文请求断开了,客户端还没有给我回应,应该是我发送的请求断开报文它没有收到,于是服务器又会重新发送一次,而客户端就能在这个2MSL时间段内收到这个重传的报文,接着给出回应报文,并且会重启2MSL计时器。

    • 第二,防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后,在这个2MSL时间中,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

    为什么建立连接是三次握手,关闭连接确是四次挥手呢?

    • 建立连接的时候, 服务器在LISTEN状态下,收到建立连接请求的SYN报文后,把ACK和SYN放在一个报文里发送给客户端。
      而关闭连接时,服务器收到对方的FIN报文时,仅仅表示对方不再发送数据了但是还能接收数据,而自己也未必全部数据都发送给对方了,所以己方可以立即关闭,也可以发送一些数据给对方后,再发送FIN报文给对方来表示同意现在关闭连接,因此,己方ACK和FIN一般都会分开发送,从而导致多了一次。

    如果已经建立了连接, 但是客户端突发故障了怎么办?

    • TCP设有一个保活计时器,显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。

    理解TIME_WAIT状态

    可以做一个实验, 先运行server, 再运行client连接server, 然后断开server, 再立马运行server.
    我们会发现:
    这里写图片描述

    绑定的时候出了问题.
    这是因为,虽然server应用程序终止了,但TCP协议层的连接并没有完全断开,因此不能再次监听绑定同样的server端口.

    TCP协议规定,主动关闭连接的一方要处于TIME_ WAIT状态,等待2*MSL(maximum segment lifetime)的时间后才能回到CLOSED状态.
    我们使用Ctrl-C终止了server, 所以server是主动关闭连接的一方, 在TIME_WAIT期间仍然不能再次监听同样的server端口
    MSL在RFC1122中规定为两分钟,但是各操作系统的实现不同, 在Centos7上默认配置的值是60s;
    可以通过 cat /proc/sys/net/ipv4/tcp_fin_timeout 查看MSL的值
    这里写图片描述
    解决TIME_WAIT引起的bind失败问题
    在server的TCP连接没有完全断开之前不允许重新监听, 某些情况下可能是不合理的.

    比如:

    服务器需要处理非常大量的客户端的连接(每个连接的生存时间可能很短, 但是每秒都有大量的客户端来请求).
    这个时候如果由服务器端主动关闭连接(比如某些客户端不活跃, 就需要被服务器端主动清理掉), 就会产生大量TIME_WAIT连接.
    由于我们的请求量很大, 就可能导致TIME_WAIT的连接数很多, 导致服务器的端口不够用, 无法处理新的连接.

    解决方法:
    - 使用setsockopt()设置socket描述符的选项SO_REUSEADDR为1, 表示允许创建端口号相同但IP地址不同的多个socket描述符.

    用法:

    • 在server代码的socket()和bind()调用之间插入如下代码

      int opt = 1;
      setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));

    确认应答机制(ACK机制)

    这里写图片描述

    TCP将每个字节的数据都进行了编号, 即为序列号.
    这里写图片描述

    每一个ACK都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据; 下一次你要从哪里开始发.
    比如, 客户端向服务器发送了1005字节的数据, 服务器返回给客户端的确认序号是1003, 那么说明服务器只收到了1-1002的数据.
    1003, 1004, 1005都没收到.
    此时客户端就会从1003开始重发.

    超时重传机制

    这里写图片描述

    主机A发送数据给B之后, 可能因为网络拥堵等原因, 数据无法到达主机B
    如果主机A在一个特定时间间隔内没有收到B发来的确认应答, 就会进行重发
    但是主机A没收到确认应答也可能是ACK丢失了.
    这里写图片描述

    这种情况下, 主机B会收到很多重复数据.
    那么TCP协议需要识别出哪些包是重复的, 并且把重复的丢弃.
    这时候利用前面提到的序列号, 就可以很容易做到去重.

    超时时间如何确定?
    最理想的情况下, 找到一个最小的时间, 保证 “确认应答一定能在这个时间内返回”.
    但是这个时间的长短, 随着网络环境的不同, 是有差异的.
    如果超时时间设的太长, 会影响整体的重传效率; 如果超时时间设的太短, 有可能会频繁发送重复的包.

    TCP为了保证任何环境下都能保持较高性能的通信, 因此会动态计算这个最大超时时间.

    • Linux中(BSD Unix和Windows也是如此), 超时以500ms为一个单位进行控制, 每次判定超时重发的超时时间都是500ms的整数倍.
      如果重发一次之后, 仍然得不到应答, 等待 2*500ms 后再进行重传. 如果仍然得不到应答, 等待 4*500ms 进行重传.
      依次类推, 以指数形式递增. 累计到一定的重传次数, TCP认为网络异常或者对端主机出现异常, 强制关闭连接.

    滑动窗口

    刚才我们讨论了确认应答机制, 对每一个发送的数据段, 都要给一个ACK确认应答. 收到ACK后再发送下一个数据段.
    这样做有一个比较大的缺点, 就是性能较差. 尤其是数据往返时间较长的时候.
    那么我们可不可以一次发送多个数据段呢?
    例如这样:
    这里写图片描述
    一个概念: 窗口
    窗口大小指的是无需等待确认应答就可以继续发送数据的最大值.
    上图的窗口大小就是4000个字节 (四个段).

    发送前四个段的时候, 不需要等待任何ACK, 直接发送
    收到第一个ACK确认应答后, 窗口向后移动, 继续发送第五六七八段的数据…

    因为这个窗口不断向后滑动, 所以叫做滑动窗口.
    操作系统内核为了维护这个滑动窗口, 需要开辟发送缓冲区来记录当前还有哪些数据没有应答
    只有ACK确认应答过的数据, 才能从缓冲区删掉.
    这里写图片描述

    如果出现了丢包, 那么该如何进行重传呢?

    此时分两种情况讨论:

    1, 数据包已经收到, 但确认应答ACK丢了.
    这里写图片描述
    这种情况下, 部分ACK丢失并无大碍, 因为还可以通过后续的ACK来确认对方已经收到了哪些数据包.

    2, 数据包丢失
    这里写图片描述

    当某一段报文丢失之后, 发送端会一直收到 1001 这样的ACK, 就像是在提醒发送端 “我想要的是 1001”
    如果发送端主机连续三次收到了同样一个 “1001” 这样的应答, 就会将对应的数据 1001 - 2000 重新发送
    这个时候接收端收到了 1001 之后, 再次返回的ACK就是7001了
    因为2001 - 7000接收端其实之前就已经收到了, 被放到了接收端操作系统内核的接收缓冲区中.

    这种机制被称为 “高速重发控制” ( 也叫 “快重传” )

    流量控制

    接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被填满, 这个时候如果发送端继续发送, 就会造成丢包, 进而引起丢包重传等一系列连锁反应.
    因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度.
    这个机制就叫做 流量控制(Flow Control)

    接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段,
    通过ACK通知发送端;
    窗口大小越大, 说明网络的吞吐量越高;
    接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;
    发送端接受到这个窗口大小的通知之后, 就会减慢自己的发送速度;
    如果接收端缓冲区满了, 就会将窗口置为0;
    这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 让接收端把窗口大小再告诉发送端.

    这里写图片描述

    那么接收端如何把窗口大小告诉发送端呢?
    我们的TCP首部中, 有一个16位窗口大小字段, 就存放了窗口大小的信息;
    16位数字最大表示65536, 那么TCP窗口最大就是65536字节么?
    实际上, TCP首部40字节选项中还包含了一个窗口扩大因子M, 实际窗口大小是窗口字段的值左移 M 位(左移一位相当于乘以2).

    拥塞控制

    虽然TCP有了滑动窗口这个大杀器, 能够高效可靠地发送大量数据.
    但是如果在刚开始就发送大量的数据, 仍然可能引发一些问题.
    因为网络上有很多计算机, 可能当前的网络状态已经比较拥堵.
    在不清楚当前网络状态的情况下, 贸然发送大量数据, 很有可能雪上加霜.

    因此, TCP引入 慢启动 机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态以后, 再决定按照多大的速度传输数据.

    这里写图片描述

    在此引入一个概念 拥塞窗口

    • 发送开始的时候, 定义拥塞窗口大小为1;
    • 每次收到一个ACK应答, 拥塞窗口加1;
    • 每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口

    像上面这样的拥塞窗口增长速度, 是指数级别的.
    “慢启动” 只是指初使时慢, 但是增长速度非常快.
    为了不增长得那么快, 此处引入一个名词叫做慢启动的阈值, 当拥塞窗口的大小超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长.

    这里写图片描述

    • 当TCP开始启动的时候, 慢启动阈值等于窗口最大值
    • 在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1

    少量的丢包, 我们仅仅是触发超时重传;
    大量的丢包, 我们就认为是网络拥塞;
    当TCP通信开始后, 网络吞吐量会逐渐上升;
    随着网络发生拥堵, 吞吐量会立刻下降.

    拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案.

    延迟应答

    如果接收数据的主机立刻返回ACK应答, 这时候返回的窗口可能比较小.
    假设接收端缓冲区为1M. 一次收到了500K的数据;
    如果立刻应答, 返回的窗口大小就是500K;
    但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了; 在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来;
    如果接收端稍微等一会儿再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M

    窗口越大, 网络吞吐量就越大, 传输效率就越高.
    TCP的目标是在保证网络不拥堵的情况下尽量提高传输效率;

    那么所有的数据包都可以延迟应答么?
    肯定也不是
    有两个限制

    • 数量限制: 每隔N个包就应答一次
    • 时间限制: 超过最大延迟时间就应答一次

    具体的数量N和最大延迟时间, 依操作系统不同也有差异
    一般 N 取2, 最大延迟时间取200ms

    捎带应答

    在延迟应答的基础上, 我们发现, 很多情况下
    客户端和服务器在应用层也是 “一发一收” 的
    意味着客户端给服务器说了 “How are you”
    服务器也会给客户端回一个 “Fine, thank you”
    那么这个时候ACK就可以搭顺风车, 和服务器回应的 “Fine, thank you” 一起发送给客户端
    这里写图片描述

    面向字节流

    创建一个TCP的socket, 同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区;
    调用write时, 数据会先写入发送缓冲区中;
    如果发送的字节数太大, 会被拆分成多个TCP的数据包发出;
    如果发送的字节数太小, 就会先在缓冲区里等待, 等到缓冲区大小差不多了, 或者到了其他合适的时机再发送出去;
    接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;
    然后应用程序可以调用read从接收缓冲区拿数据;
    另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区,
    那么对于这一个连接, 既可以读数据, 也可以写数据, 这个概念叫做 全双工

    由于缓冲区的存在, 所以TCP程序的读和写不需要一一匹配
    例如:

    • 写100个字节的数据, 可以调用一次write写100个字节, 也可以调用100次write, 每次写一个字节;
    • 读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100个字节, 也可以一次read一个字节, 重复100次;

    粘包问题

    首先要明确, 粘包问题中的 “包”, 是指应用层的数据包.
    在TCP的协议头中, 没有如同UDP一样的 “报文长度” 字段
    但是有一个序号字段.
    站在传输层的角度, TCP是一个一个报文传过来的. 按照序号排好序放在缓冲区中.
    站在应用层的角度, 看到的只是一串连续的字节数据.
    那么应用程序看到了这一连串的字节数据, 就不知道从哪个部分开始到哪个部分是一个完整的应用层数据包.
    此时数据之间就没有了边界, 就产生了粘包问题

    那么如何避免粘包问题呢?
    归根结底就是一句话, 明确两个包之间的边界

    对于定长的包
    - 保证每次都按固定大小读取即可
    例如上面的Request结构, 是固定大小的, 那么就从缓冲区从头开始按sizeof(Request)依次读取即可

    对于变长的包
    - 可以在数据包的头部, 约定一个数据包总长度的字段, 从而就知道了包的结束位置
    还可以在包和包之间使用明确的分隔符来作为边界(应用层协议, 是程序员自己来定的, 只要保证分隔符不和正文冲突即可)

    对于UDP协议来说, 是否也存在 “粘包问题” 呢?

    对于UDP, 如果还没有向上层交付数据, UDP的报文长度仍然存在.
    同时, UDP是一个一个把数据交付给应用层的, 就有很明确的数据边界.
    站在应用层的角度, 使用UDP的时候, 要么收到完整的UDP报文, 要么不收.
    不会出现收到 “半个” 的情况.

    TCP 异常情况

    • 进程终止: 进程终止会释放文件描述符, 仍然可以发送FIN. 和正常关闭没有什么区别.
    • 机器重启: 和进程终止的情况相同.
    • 机器掉电/网线断开: 接收端认为连接还在, 一旦接收端有写入操作, 接收端发现连接已经不在了, 就会进行 reset. 即使没有写入操作, TCP自己也内置了一个保活定时器, 会定期询问对方是否还在. 如果对方不在, 也会把连接释放.
    • 另外, 应用层的某些协议, 也有一些这样的检测机制.
      例如HTTP长连接中, 也会定期检测对方的状态.
      例如QQ, 在QQ断线之后, 也会定期尝试重新连接.

    TCP 小结

    为什么TCP这么复杂?

    因为既要保证可靠性, 同时又要尽可能提高性能.

    保证可靠性的机制

    • 校验和
    • 序列号(按序到达)
    • 确认应答
    • 超时重传
    • 连接管理
    • 流量控制
    • 拥塞控制

    提高性能的机制

    • 滑动窗口
    • 快速重传
    • 延迟应答
    • 捎带应答

    定时器

    • 超时重传定时器
    • 保活定时器
    • TIME_WAIT定时器

    基于 TCP 的应用层协议

    HTTP
    HTTPS
    SSH
    Telnet
    FTP
    SMTP

    当然, 也包括我们自己写TCP程序时自定义的应用层协议

    TCP 和 UDP 对比

    我们说了TCP是可靠连接, 那么是不是TCP一定就优于UDP呢?

    TCP和UDP之间的优点和缺点, 不能简单绝对地进行比较
    TCP用于可靠传输的情况, 应用于文件传输, 重要状态更新等场景
    UDP用于对高速传输和实时性要求较高的通信领域
    例如, 早期的QQ, 视频传输等. 另外UDP可以用于广播

    归根结底, TCP和UDP都是一种工具, 什么时机用, 具体怎么用, 还是要根据具体的需求场景去决定.

    展开全文
  • TCP和UDP的区别和优缺点

    万次阅读 多人点赞 2017-08-06 22:59:09
    1、TCP与UDP区别总结: 1、TCP面向连接(如打电话要先拨号建立连接);UDP是无连接的,即发送数据之前不需要建立连接 2、TCP提供可靠的服务。也就是说,通过TCP连接传送的数据,无差错,不丢失,不重复,且按序到达;...
    1、TCP与UDP区别总结:
    1、TCP面向连接(如打电话要先拨号建立连接);UDP是无连接的,即发送数据之前不需要建立连接

    2、TCP提供可靠的服务。也就是说,通过TCP连接传送的数据,无差错,不丢失,不重复,且按序到达;UDP尽最大努力交付,即不保证可靠交付

    Tcp通过校验和,重传控制,序号标识,滑动窗口、确认应答实现可靠传输。如丢包时的重发控制,还可以对次序乱掉的分包进行顺序控制。

    3、UDP具有较好的实时性,工作效率比TCP高,适用于对高速传输和实时性有较高的通信或广播通信。

    4.每一条TCP连接只能是点到点的;UDP支持一对一,一对多,多对一和多对多的交互通信

    5、TCP对系统资源要求较多,UDP对系统资源要求较少。


    2、为什么UDP有时比TCP更有优势?

    UDP以其简单、传输快的优势,在越来越多场景下取代了TCP,如实时游戏。

    (1)网速的提升给UDP的稳定性提供可靠网络保障,丢包率很低,如果使用应用层重传,能够确保传输的可靠性。

    (2)TCP为了实现网络通信的可靠性,使用了复杂的拥塞控制算法,建立了繁琐的握手过程,由于TCP内置的系统协议栈中,极难对其进行改进。

    采用TCP,一旦发生丢包,TCP会将后续的包缓存起来,等前面的包重传并接收到后再继续发送,延时会越来越大,基于UDP对实时性要求较为严格的情况下,采用自定义重传机制,能够把丢包产生的延迟降到最低,尽量减少网络问题对游戏性造成影响。

    3、UDP和TCP编程步骤也有些不同,如下:

    TCP: 
    TCP编程的服务器端一般步骤是: 
      1、创建一个socket,用函数socket();     SOCKET SocketListen =socket(AF_INET,SOCK_STREAM, IPPROTO_TCP);
      2、设置socket属性,用函数setsockopt(); * 可选 
      3、绑定IP地址、端口等信息到socket上,用函数bind(); SOCKET_ERROR = bind(SocketListen,(const sockaddr*)&addr,sizeof(addr))
      4、开启监听,用函数listen();                 SOCKET_ERROR == listen(SocketListen,2)
      5、接收客户端上来的连接,用函数accept();    SOCKET SocketWaiter = accept(SocketListen,

                                                      _Out_    struct sockaddr *addr

     _Inout_  int *addrlen);
      6、收发数据,用函数send()和recv(),或者read()和write(); 
      7、关闭网络连接; closesocket(SocketListen);closesocket(SocketWaiter);
      8、关闭监听; 
    SOCK_STREAM这种的特点是面向连接的,即每次收发数据之前必须通过connect建立连接,而SOCK_DGRAM这种是User Datagram Protocol协议的网络通讯,它是无连接的,不可靠的。
    TCP编程的客户端一般步骤是: 
      1、创建一个socket,用函数socket(); 
      2、设置socket属性,用函数setsockopt();* 可选 
      3、绑定IP地址、端口等信息到socket上,用函数bind();* 可选 
      4、设置要连接的对方的IP地址和端口等属性; 
      5、连接服务器,用函数connect(); 
      6、收发数据,用函数send()和recv(),或者read()和write(); 
      7、关闭网络连接;

    int send(
      _In_  SOCKET s,         //向哪个socket发送,accept返回的socket。
      _In_  const char *buf,
      _In_  int len,
      _In_  int flags
    );                               由于
    
    send(SocketClient,(const char *)&fh,sizeof(fh),0);

    recv(SocketClient,szbuf,sizeof(szbuf),0);
    UDP:
    与之对应的UDP编程步骤要简单许多,分别如下: 
      UDP编程的服务器端一般步骤是: 
      1、创建一个socket,用函数socket(); 
      2、设置socket属性,用函数setsockopt();* 可选 
      3、绑定IP地址、端口等信息到socket上,用函数bind(); 
      4、循环接收数据,用函数recvfrom(); 
      5、关闭网络连接; 

    UDP编程的客户端一般步骤是: 
      1、创建一个socket,用函数socket(); 
      2、设置socket属性,用函数setsockopt();* 可选 
      3、绑定IP地址、端口等信息到socket上,用函数bind();* 可选 
      4、设置对方的IP地址和端口等属性; 
      5、发送数据,用函数sendto(); 
      6、关闭网络连接;

    int recvfrom(
      _In_         SOCKET s,       //绑定的socket
      _Out_        char *buf,
      _In_         int len,
      _In_         int flags,
      _Out_        struct sockaddr *from,  //用来接收对方的
      _Inout_opt_  int *fromlen
    );
    int nres=recvfrom(pThis->m_socketListen,szBuf,sizeof(szBuf),0,(sockaddr*)&addrClient,&nSize);//0处标志位
    sendto(m_socketListen,szBuffer,nSize,0,(const sockaddr*)&addr,sizeof(sockaddr_in))
    TCP和UDP是OSI模型中的运输层中的协议。TCP提供可靠的通信传输,而UDP则常被用于让广播和细节控制交给应用的通信传输。


    4、将socket设置为广播属性
    bool optval=true;
    setsockopt(m_socketListen,SOL_SOCKET,SO_BROADCAST,(const char *)&optval,sizeof(bool));

    5、将Socket设置为非阻塞。
    //bool benable=true;
    //ioctlsocket(m_socketListen,FIONBIO,(u_long*)&benable);

    6、Tcp头,20字节

    7、UDP首部,8个字节

    展开全文
  • 一文详解TCP

    千次阅读 多人点赞 2020-04-27 13:22:55
    记得以前面试的时候被面试官问起TIME_WAIT有什么痛点,当时只记得TCP三次握手、四次挥手之类的,至于其中的某个状态还真是记不起来,之前也没有过多关注过,还有对于拥塞控制的概念也比较模糊。 TCP报文格式 TCP...

    欢迎支持笔者新作:《深入理解Kafka:核心设计与实践原理》和《RabbitMQ实战指南》,同时欢迎关注笔者的微信公众号:朱小厮的博客。

    欢迎跳转到本文的原文链接:https://honeypps.com/network/tcp-introduction/


    记得以前面试的时候被面试官问起TIME_WAIT有什么痛点,当时只记得TCP三次握手、四次挥手之类的,至于其中的某个状态还真是记不起来,之前也没有过多关注过,还有对于拥塞控制的概念也比较模糊。

    TCP报文格式

    TCP大家都知道是什么东西,这个协议的具体报文格式如下:

    (图1)

    标志位

    • URG:指示报文中有紧急数据,应尽快传送(相当于高优先级的数据)。
    • PSH:为1表示是带有push标志的数据,指示接收方在接收到该报文段以后,应尽快将这个报文段交给应用程序,而不是在缓冲区排队。
    • RST:TCP连接中出现严重差错(如主机崩溃),必须释放连接,在重新建立连接。
    • FIN:发送端已完成数据传输,请求释放连接。
    • SYN:处于TCP连接建立过程。 (Synchronize Sequence Numbers)
    • ACK:确认序号标志,为1时表示确认号有效,为0表示报文中不含确认信息,忽略确认号字段。

    窗口
    滑动窗口大小,这个字段是接收端用来告知发送端自己还有多少缓冲区可以接受数据。于是发送端可以根据这个接收端的处理能力来发送数据,而不会导致接收端处理不过来。(以此控制发送端发送数据的速率,从而达到流量控制。)窗口大小时一个16bit字段,因而窗口大小最大为65535。

    头部长度(首部长度)
    由于TCP首部包含一个长度可变的选项和填充部分,所以需要这么一个值来指定这个TCP报文段到底有多长。或者可以这么理解:就是表示TCP报文段中数据部分在整个TCP报文段中的位置。该字段的单位是32位字,即:4个字节。TCP的滑动窗口大小实际上就是socket的接收缓冲区大小的字节数。

    选项和填充部分
    TCP报文的字段实现了TCP的功能,标识进程、对字节流拆分组装、差错控制、流量控制、建立和释放连接等。其最大长度可根据TCP首部长度进行推算。TCP首部长度用4位表示,那么选项部分最长为:(2^4-1)*(32/8)-20=40字节。

    三次握手

    (图2)

    最开始的时候客户端和服务器都是处于CLOSED状态。主动打开连接的为客户端,被动打开连接的是服务器。

    1. TCP服务器进程先创建传输控制块TCB,时刻准备接受客户进程的连接请求,此时服务器就进入了**LISTEN(监听)**状态;
    2. TCP客户进程也是先创建传输控制块TCB,然后向服务器发出连接请求报文,这是报文首部中的**同部位SYN=1,同时选择一个初始序列号 seq=x **,此时,TCP客户端进程进入了 SYN-SENT(同步已发送状态)状态。TCP规定,SYN报文段(SYN=1的报文段)不能携带数据,但需要消耗掉一个序号。
    3. TCP服务器收到请求报文后,如果同意连接,则发出确认报文。确认报文中应该 ACK=1,SYN=1,确认号是ack=x+1,同时也要为自己初始化一个序列号 seq=y,此时,TCP服务器进程进入了**SYN-RCVD(同步收到)**状态。这个报文也不能携带数据,但是同样要消耗一个序号。
    4. TCP客户进程收到确认后,还要向服务器给出确认。确认报文的ACK=1,ack=y+1,自己的序列号seq=x+1,此时,TCP连接建立,客户端进入**ESTABLISHED(已建立连接)**状态。TCP规定,ACK报文段可以携带数据,但是如果不携带数据则不消耗序号。
    5. 当服务器收到客户端的确认后也进入ESTABLISHED状态,此后双方就可以开始通信了。

    三次握手主要目的是:信息对等和防止超时。防止超时导致脏连接。如果使用的是两次握手建立连接,假设有这样一种场景,客户端发送了第一个请求连接并且没有丢失,只是因为在网络结点中滞留的时间太长了,由于TCP的客户端迟迟没有收到确认报文,以为服务器没有收到,此时重新向服务器发送这条报文,此后客户端和服务器经过两次握手完成连接,传输数据,然后关闭连接。此时此前滞留的那一次请求连接,网络通畅了到达了服务器,这个报文本该是失效的,但是,两次握手的机制将会让客户端和服务器再次建立连接,这将导致不必要的错误和资源的浪费。如果采用的是三次握手,就算是那一次失效的报文传送过来了,服务端接受到了那条失效报文并且回复了确认报文,但是客户端不会再次发出确认。由于服务器收不到确认,就知道客户端并没有请求连接。

    四次挥手

    (图3)

    数据传输完毕后,双方都可释放连接。最开始的时候,客户端和服务器都是处于ESTABLISHED状态,然后客户端主动关闭,服务器被动关闭。

    1. 客户端进程发出连接释放报文,并且停止发送数据。释放数据报文首部,FIN=1,其序列号为seq=u(等于前面已经传送过来的数据的最后一个字节的序号加1),此时,客户端进入FIN-WAIT-1(终止等待1)状态。 TCP规定,FIN报文段即使不携带数据,也要消耗一个序号。
    2. 服务器收到连接释放报文,发出确认报文,ACK=1,ack=u+1,并且带上自己的序列号seq=v,此时,服务端就进入了CLOSE-WAIT(关闭等待)状态。TCP服务器通知高层的应用进程,客户端向服务器的方向就释放了,这时候处于半关闭状态,即客户端已经没有数据要发送了,但是服务器若发送数据,客户端依然要接受。这个状态还要持续一段时间,也就是整个CLOSE-WAIT状态持续的时间。
    3. 客户端收到服务器的确认请求后,此时,客户端就进入**FIN-WAIT-2(终止等待2)**状态,等待服务器发送连接释放报文(在这之前还需要接受服务器发送的最后的数据)。
    4. 服务器将最后的数据发送完毕后,就向客户端发送连接释放报文,FIN=1,ack=u+1,由于在半关闭状态,服务器很可能又发送了一些数据,假定此时的序列号为seq=w,此时,服务器就进入了**LAST-ACK(最后确认)**状态,等待客户端的确认。
    5. 客户端收到服务器的连接释放报文后,必须发出确认,ACK=1,ack=w+1,而自己的序列号是seq=u+1,此时,客户端就进入了TIME-WAIT(时间等待)状态。注意此时TCP连接还没有释放,必须经过2MSL(最长报文段寿命)的时间后,当客户端撤销相应的TCB后,才进入CLOSED状态。
    6. 服务器只要收到了客户端发出的确认,立即进入CLOSED状态。同样,撤销TCB后,就结束了这次的TCP连接。可以看到,服务器结束TCP连接的时间要比客户端早一些。

    TIME_WAIT:主动要求关闭的机器表示收到了对方的FIN报文,并发送出了ACK报文,进入TIME_WAIT状态,等2MSL后即可进入到CLOSED状态。如果FIN_WAIT_1状态下,同时收到待FIN标识和ACK标识的报文时,可以直接进入TIME_WAIT状态,而无需经过FIN_WAIT_2状态。

    CLOSE_WAIT:被动关闭的机器收到对方请求关闭连接的FIN报文,在第一次ACK应答后,马上进入CLOSE_WAIT状态。这种状态其实标识在等待关闭,并且通知应用发送剩余数据,处理现场信息,关闭相关资源。

    为什么客户端最后还要等待2MSL?
    MSL(Maximum Segment Lifetime),TCP允许不同的实现可以设置不同的MSL值。**第一,保证客户端发送的最后一个ACK报文能够到达服务器,因为这个ACK报文可能丢失。**站在服务器的角度看来,我已经发送了FIN+ACK报文请求断开了,客户端还没有给我回应,应该是我发送的请求断开报文它没有收到,于是服务器又会重新发送一次,而客户端就能在这个2MSL时间段内收到这个重传的报文,接着给出回应报文,并且会重启2MSL计时器。如果客户端收到服务端的FIN+ACK报文后,发送一个ACK给服务端之后就“自私”地立马进入CLOSED状态,可能会导致服务端无法确认收到最后的ACK指令,也就无法进入CLOSED状态,这是客户端不负责任的表现。**第二,防止失效请求。**防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后,在这个2MSL时间中,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

    在TIME_WAIT状态无法真正释放句柄资源,在此期间,Socket中使用的本地端口在默认情况下不能再被使用。该限制对于客户端机器来说是无所谓的,但对于高并发服务器来说,会极大地限制有效连接的创建数量,称为性能瓶颈。所以建议将高并发服务器TIME_WAIT超时时间调小。RFC793中规定MSL为2分钟。但是在当前的高速网络中,2分钟的等待时间会造成资源的极大浪费,在高并发服务器上通常会使用更小的值。
    在服务器上通过变更/etc/sysctl.conf文件来修改该默认值net.ipv4.tcp_fin_timout=30(建议小30s)。修改完之后执行 /sbin/sysctl -p 让参数生效。
    通过如下命令查看各连接状态的技术情况:

    [root@node1 ~]# netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
    TIME_WAIT 63
    ESTABLISHED 13
    

    为什么建立连接是三次握手,关闭连接确是四次挥手呢?
    建立连接的时候, 服务器在LISTEN状态下,收到建立连接请求的SYN报文后,把ACK和SYN放在一个报文里发送给客户端。 而关闭连接时,服务器收到对方的FIN报文时,仅仅表示对方不再发送数据了但是还能接收数据,而自己也未必全部数据都发送给对方了,所以己方可以立即关闭,也可以发送一些数据给对方后,再发送FIN报文给对方来表示同意现在关闭连接,因此,己方ACK和FIN一般都会分开发送,从而导致多了一次。

    滑动窗口

    TCP滑动窗口技术通过动态改变窗口大小来调节两台主机间数据传输。每个TCP/IP主机支持全双工数据传输,因此TCP有两个滑动窗口:一个用于接收数据,另一个用于发送数据。TCP使用肯定确认技术,其确认号指的是下一个所期待的字节。 假定发送方设备以每一次三个数据包的方式发送数据,也就是说,窗口大小为3。发送方发送序列号为1、2、3的三个数据包,接收方设备成功接收数据包,用序列号4确认。发送方设备收到确认,继续以窗口大小3发送数据。当接收方设备要求降低或者增大网络流量时,可以对窗口大小进行减小或者增加,本例降低窗口大小为2,每一次发送两个数据包。当接收方设备要求窗口大小为0,表明接收方已经接收了全部数据,或者接收方应用程序没有时间读取数据,要求暂停发送。发送方接收到携带窗口号为0的确认,停止这一方向的数据传输。当链路变好了或者变差了这个窗口还会发生变话,并不是第一次协商好了以后就永远不变了。

    滑动窗口协议,是TCP使用的一种流量控制方法。该协议允许发送方在停止并等待确认前可以连续发送多个分组。由于发送方不必每发一个分组就停下来等待确认,因此该协议可以加速数据的传输。 只有在接收窗口向前滑动时(与此同时也发送了确认),发送窗口才有可能向前滑动。收发两端的窗口按照以上规律不断地向前滑动,因此这种协议又称为滑动窗口协议。

    流量控制:端到端,接收端的应用层处理速度决定和网速无关,由接收端返回的rwnd控制

    cwnd:发送端窗口( congestion window )
    rwnd:接收端窗口(receiver window)

    拥塞控制

    拥塞控制: 发送端主动控制cwnd,有慢启动(从cwnd初始为1开始启动,指数启动),拥塞避免(到达ssthresh后,为了避免拥塞开始尝试线性增长),快重传(接收方每收到一个报文段都要回复一个当前最大连续位置的确认,发送方只要一连收到三个重复确认就知道接收方丢包了,快速重传丢包的报文,并TCP马上把拥塞窗口 cwnd 减小到1),快恢复(直接从ssthresh线性增长)。

    如果网络上的延时突然增加,那么TCP对这个事作出的应对只有重传数据,但是重传会导致网络的负担更重,于是会导致更大的延迟以及更多的丢包,于是这个情况就会进入恶性循环被不断地放大。试想一下,如果一个网络内有成千上万的TCP连接都这么行事,那么马上就会形成“网络风暴”,TCP这个协议就会拖垮整个网络。所以TCP不能忽略网络上发生的事情,而无脑地一个劲地重发数据,对网络造成更大的伤害。对此TCP的设计理念是:TCP不是一个自私的协议,当拥塞发生的时候,要做自我牺牲。就像交通阻塞一样,每个车都应该把路让出来,而不要再去抢路了。

    慢启动
    只有在TCP连接建立和网络出现超时时才使用。每经过一个传输轮次,拥塞窗口 cwnd 就加倍。一个传输轮次所经历的时间其实就是往返时间RTT。不过“传输轮次”更加强调:把拥塞窗口cwnd所允许发送的报文段都连续发送出去,并收到了对已发送的最后一个字节的确认。另外,慢开始的“慢”并不是指cwnd的增长速率慢,而是指在TCP开始发送报文段时先设置cwnd=1,使得发送方在开始时只发送一个报文段(目的是试探一下网络的拥塞情况),然后再逐渐增大cwnd。

    为了防止拥塞窗口cwnd增长过大引起网络拥塞,还需要设置一个慢开始门限ssthresh状态变量(如何设置ssthresh)。慢开始门限ssthresh的用法如下:

    • 当 cwnd < ssthresh 时,使用上述的慢开始算法。
    • 当 cwnd > ssthresh 时,停止使用慢开始算法而改用拥塞避免算法。
    • 当 cwnd = ssthresh 时,既可使用慢开始算法,也可使用拥塞控制避免算法。

    拥塞避免算法:让拥塞窗口cwnd缓慢地增大,即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1,而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长,比慢开始算法的拥塞窗口增长速率缓慢得多。

    (图4)

    无论在慢开始阶段还是在拥塞避免阶段,只要发送方判断网络出现拥塞(其根据就是没有收到确认),就要把慢开始门限ssthresh设置为出现拥塞时的发送方窗口值的一半(但不能小于2)。然后把拥塞窗口cwnd重新设置为1,执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数,使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。

    1. 当TCP连接进行初始化时,把拥塞窗口cwnd置为1。前面已说过,为了便于理解,图中的窗口单位不使用字节而使用报文段的个数。慢开始门限的初始值设置为16个报文段,即 cwnd = 16 。
    2. 在执行慢开始算法时,拥塞窗口 cwnd 的初始值为1。以后发送方每收到一个对新报文段的确认ACK,就把拥塞窗口值另1,然后开始下一轮的传输(图中横坐标为传输轮次)。因此拥塞窗口cwnd随着传输轮次按指数规律增长。当拥塞窗口cwnd增长到慢开始门限值ssthresh时(即当cwnd=16时),就改为执行拥塞控制算法,拥塞窗口按线性规律增长。
    3. 假定拥塞窗口的数值增长到24时,网络出现超时(这很可能就是网络发生拥塞了)。更新后的ssthresh值变为12(即变为出现超时时的拥塞窗口数值24的一半),拥塞窗口再重新设置为1,并执行慢开始算法。当cwnd=ssthresh=12时改为执行拥塞避免算法,拥塞窗口按线性规律增长,每经过一个往返时间增加一个MSS的大小。

    强调:“拥塞避免”并非指完全能够避免了拥塞。利用以上的措施要完全避免网络拥塞还是不可能的。“拥塞避免”是说在拥塞避免阶段将拥塞窗口控制为按线性规律增长,使网络比较不容易出现拥塞。

    如果发送方设置的超时计时器时限已到但还没有收到确认,那么很可能是网络出现了拥塞,致使报文段在网络中的某处被丢弃。这时,TCP马上把拥塞窗口 cwnd 减小到1,并执行慢开始算法,同时把慢开始门限值ssthresh减半。这是不使用快重传的情况。快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方)而不要等到自己发送数据时才进行捎带确认。

    (图5)

    接收方收到了M1和M2后都分别发出了确认。现在假定接收方没有收到M3但接着收到了M4。显然,接收方不能确认M4,因为M4是收到的失序报文段。根据可靠传输原理,接收方可以什么都不做,也可以在适当时机发送一次对M2的确认。但按照快重传算法的规定,接收方应及时发送对M2的重复确认,这样做可以让发送方及早知道报文段M3没有到达接收方。发送方接着发送了M5和M6。接收方收到这两个报文后,也还要再次发出对M2的重复确认。这样,发送方共收到了接收方的四个对M2的确认,其中后三个都是重复确认。快重传算法还规定,发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段M3,而不必继续等待M3设置的重传计时器到期。由于发送方尽早重传未被确认的报文段,因此采用快重传后可以使整个网络吞吐量提高约20%。

    (图6)

    与快重传配合使用的还有快恢复算法,其过程有以下两个要点:

    1. 当发送方连续收到三个重复确认,就执行“乘法减小”算法,把慢启动门限ssthresh减半。这是为了预防网络发生拥塞。请注意:接下去不执行慢开始算法。
    2. 由于发送方现在认为网络很可能没有发生拥塞,因此与慢开始不同之处是现在不执行慢开始算法(即拥塞窗口cwnd现在不设置为1),而是把cwnd值设置为慢开始门限ssthresh减半后的数值,然后开始执行拥塞避免算法(“加法增大”),使拥塞窗口缓慢地线性增大。

    上图给出了快重传和快恢复的示意图,并标明了“TCP Reno版本”。区别:新的 TCP Reno 版本在快重传之后采用快恢复算法而不是采用慢开始算法。

    发送方窗口的上限值 = Min [ rwnd, cwnd ]

    • 当rwnd < cwnd 时,是接收方的接收能力限制发送方窗口的最大值。
    • 当cwnd < rwnd 时,则是网络的拥塞限制发送方窗口的最大值。

    差错控制

    TCP使用差错控制来提供可靠性。差错控制包括以下的一些机制:检测和重传受到损伤的报文段、重传丢失的报文段、保存失序到达的报文段直至缺失的报文到期,以及检测和丢弃重复的报文段。TCP通过三个简单的工具来完成其差错控制:检验和确认以及超时

    参考资料:

    1. https://blog.csdn.net/ligupeng7929/article/details/79597423
    2. https://blog.csdn.net/qzcsu/article/details/72861891
    3. https://www.cnblogs.com/zlingh/p/6161088.html

    欢迎跳转到本文的原文链接:https://honeypps.com/network/tcp-introduction/


    欢迎支持笔者新作:《深入理解Kafka:核心设计与实践原理》和《RabbitMQ实战指南》,同时欢迎关注笔者的微信公众号:朱小厮的博客。


    展开全文
  • TCP&UDP;测试工具 V1.02

    2020-07-24 23:33:57
    1.可收发TCP/UDP数据。 2.对于TCP,支持服务器和客户端模式。 3.支持多连接,可同时对多路网络连接进行操作。 4.对于UDP,支持组播方式。 5.可显示当前数据传输速度。 6.数据显示方式分为ASCII和HEX两种。 7.可发送...
  • STM32网络丢包问题分析

    千次阅读 2017-08-04 19:00:23
    1. 测试环境说明 硬件平台:NUCLEO-F767ZI 开发板(STM32F7,Cortex-M7,216MHz,2MB Flash,512KB ... TCP/IP协议栈:LwIP v2.0.0  这里所描述的网络丢包问题的测试程序,是使用 STM32CubeMX 工具(库版本为 STM32C
  • TCP协议详解

    万次阅读 多人点赞 2018-08-30 15:26:53
    TCP提供一种面向连接的可靠的字节流服务,面向连接意味着两个使用TCP的应用(B/S)在彼此交换数据之前,必须先建立一个TCP连接,类似于打电话过程,先拨号振铃,等待对方说喂,然后应答。在一个TCP连接中,只有两方...
  • 五分钟读懂TCP 协议——TCP协议简介

    万次阅读 多人点赞 2017-06-11 23:48:03
    TCP 是互联网核心协议之一,本文介绍它的基础知识。一、TCP 协议的作用互联网由一整套协议构成。TCP 只是其中的一层,有着自己的分工。(图片说明:TCP 是以太网协议和 IP 协议的上层协议,也是应用层协议的下层协议...
  • DDoS攻击--TCP攻击概述

    千次阅读 2018-08-22 16:14:34
    TCP协议,相信对于每一个开发工程师都不陌生。由于该协议是一个面向连接,可靠的特性,广泛应用于现在互联网的应用中。如常见的web,ssh,ftp等都是基于TCP协议。目前TCP协议占全网的流量达到80%,因此这也成为黑客...
  • 两张动图-彻底明白TCP的三次握手与四次挥手

    万次阅读 多人点赞 2020-04-06 14:22:03
    背景描述 通过上一篇中网络模型中的IP层的介绍,我们知道网络层,可以实现两个主机之间的通信。但是这并不具体,因为,真正进行通信的实体是在主机中的进程,是一个主机中的一个进程与另外一个主机中的一个进程在...
  • 动画:用动画给面试官解释 TCP 三次握手过程

    万次阅读 多人点赞 2020-04-11 22:50:08
    TCP 三次握手过程对于面试是必考的一个,所以不但要掌握 TCP 整个握手的过程,其中有些小细节也更受到面试官的青睐。 对于这部分掌握以及 TCP 的四次挥手,小鹿将会以动画的形式呈现给每个人,这样将复杂的知识简单...
  • 废话少说,我们直接上干的,学习知识,第一个是收集和查阅资料,这个是必须的。
  • TCP协议三次握手和四次握手机制-动画详解

    万次阅读 多人点赞 2019-12-22 14:28:32
    TCP三次握手和四次挥手的问题在面试中是最为常见的考点之一。很多读者都知道三次和四次,但是如果问深入一点,他们往往都无法作出准确回答。 本篇尝试使用动画来对这个知识点进行讲解,期望读者们可以更加简单地地...
  • TCP三次握手详解-深入浅出(实例演示)

    万次阅读 多人点赞 2020-10-17 23:37:52
    TCP是属于网络分层中的传输层,因为OSI分为层,感觉太麻烦了,所以分为四层就好了,简单。 分层以及每层的协议,如下两张图: TCP三次握手 TCP三次握手简单如下图: TCP三次握手的过程描述: 1.客户...
  • 深入理解TCP、UDP协议及两者的区别

    万次阅读 多人点赞 2020-07-04 17:05:19
    一、TCP协议: 位于传输层, 提供可靠的字节流服务。所谓的字节流服务(Byte Stream Service) 是指, 为了方便传输, 将大块数据分割成以报文段(segment) 为单位的数据包进行管理。 而可靠的传输服务是指, 能够...
  • TCP 和 UDP 的区别

    万次阅读 多人点赞 2019-03-23 18:36:33
    TCP TCP 的三次握手 TCP 四次挥手 累计确认 顺序问题和丢包问题 流量控制的问题 拥塞控制的问题 总结及面试问题 前言 前端的面试中经常问的 TCP 和 UDP 的区别,网上也有好多内容,比如 TCP 和 UDP ...
  • TCP协议中的三次握手和四次挥手(图解)

    万次阅读 多人点赞 2017-01-04 21:51:52
    建立TCP需要三次握手才能建立,而断开连接则需要四次握手。整个过程如下图所示: 先来看看如何建立连接的。 首先Client端发送连接请求报文,Server段接受连接后回复ACK报文,并为这次连接分配资源。Client端接收...
  • TCP/IP协议详解

    万次阅读 多人点赞 2019-05-11 11:13:01
    认识HTTP协议 它是互联网协议(Internet Protocol Suite),一个网络通信模型,是互联网的一个基本的构架。 HTTP协议是Hyper Text Transfer ... HTTP是一个基于TCP/IP通信协议来传递数据(HTML 文件, 图片文件...
  • 终于懂了TCP和UDP协议区别

    万次阅读 多人点赞 2020-08-09 13:54:29
    终于懂了TCP和UDP协议区别
1 2 3 4 5 ... 20
收藏数 1,260,065
精华内容 504,026
关键字:

tcp