tcp全连接(tcp全连接队列满了)

TCP是因特网中的传输层协议，使用三次握手协议建立连接，下面是TCP建立连接的全过程。 上图画出了TCP建立连接的过程。假定主机A是TCP客户端，B是服务端。最初两端的TCP进程都处于CLOSED状态。图中在主机下面的是TCP进程所处的状态。A是主动打开连接，B是被动打开连接。首先A向B发出连接请求报文段，这时首部中的同步位SYN=1，同时选择一个初始序号seq=x。TCP规定，SYN报文段不能携带数据，但要消耗掉一个序号。这时，A进入SYN-SENT状态。B收到请求后，向A发送确认。在确认报文段中把SYN和ACK位都置为1，确认号是ack=x+1,同时也为自己选择一个初始序号seq=y。请注意，这个报文段也不能携带数据，但同样要消耗掉一个序号。这时B进入SYN-RCVD状态。A收到B的确认后，还要向B给出确认。确认报文段的ACK置为1，确认号ack=y+1，而自己的序号seq=x+1。这时，TCP连接已经建立，A进入ESTABLISHED状态，当B收到A的确认后，也会进入ESTABLISHED状态。以上给出的连接建立过程就是常说的TCP三次握手。为什么A还要发送一次确认呢?这主要是为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。所谓已失效的连接请求报文段是这样产生的。A发送连接请求，但因连接请求报文丢失而未收到确认，于是A重发一次连接请求，成功后建立了连接。数据传输完毕后就释放了连接。现在假定A发出的第一个请求报文段并未丢失，而是在某个网络节点长时间滞留了，以致延误到连接释放以后的某个时间才到达B。本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，就误以为A又发了一次新的连接请求，于是向A发出确认报文段，同意建立连接。假如不采用三次握手，那么只要B发出确认，新的连接就建立了。由于A并未发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据。但B却以为新的运输连接已经建立了，并一直等待A发来数据，因此白白浪费了许多资源。 采用TCP三次握手的方法可以防止上述现象发生。例如在刚才的情况下，由于A不会向B的确认发出确认，连接就不会建立。下面留个思考题给大家：如果在TCP第三次握手中的报文段丢失了会发生什么情况?

TCP/IP协议是什么TCP和UDP处在同一层---运输层，但是TCP和UDP最不同的地方是，TCP提供了一种可靠的数据传输服务，TCP是面向连接的，也就是说，利用TCP通信的两台主机首先要经历一个“拨打电话”的过程，等到通信准备结束才开始传输数据，最后结束通话。所以TCP要比UDP可靠的多，UDP是把数据直接发出去，而不管对方是不是在收信，就算是UDP无法送达，也不会产生ICMP差错报文，这一经时重申了很多遍了。把TCP保证可靠性的简单工作原理:应用数据被分割成TCP认为最适合发送的数据块。这和UDP完全不同，应用程序产生的 数据报长度将保持不变。由TCP传递给IP的信息单位称为报文段或段当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能 及时收到一个确认，将重发这个报文段.当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒.TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输 过程中的任何变化。如果收到段的检验和有差错， T P将丢弃这个报文段和不确认收到此报文段(希望发端超时并重发)。既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段 的到达也可能会失序。如果必要， TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。从这段话中可以看到，TCP中保持可靠性的方式就是超时重发，这是有道理的，虽然TCP也可以用各种各样的ICMP报文来处理这些，但是这也不是可靠的，最可靠的方式就是只要不得到确认，就重新发送数据报，直到得到对方的确认为止。TCP的首部和UDP首部一样，都有发送端口号和接收端口号。但是显然，TCP的首部信息要比UDP的多，可以看到，TCP协议提供了发送和确认所需要的所有必要的信息。可以想象一个TCP数据的发送应该是如下的一个过程。双方建立连接发送方给接受方TCP数据报，然后等待对方的确认TCP数据报，如果没有，就重新发，如果有，就发送下一个数据报。接受方等待发送方的数据报，如果得到数据报并检验无误，就发送ACK(确认)数据报，并等待下一个TCP数据报的到来。直到接收到FIN(发送完成数据报)中止连接可以想见，为了建立一个TCP连接，系统可能会建立一个新的进程(最差也是一个线程)，来进行数据的传送--TCP协议TCP是一个面向连接的协议，在发送输送之前 ，双方需要确定连接。而且，发送的数据可以进行TCP层的分片处理。TCP连接的建立过程 ，可以看成是三次握手 。而连接的中断可以看成四次握手 。1.连接的建立在建立连接的时候，客户端首先向服务器申请打开某一个端口(用SYN段等于1的TCP报文)，然后服务器端发回一个ACK报文通知客户端请求报文收到，客户端收到确认报文以后再次发出确认报文确认刚才服务器端发出的确认报文(绕口么)，至此，连接的建立完成。这就叫做三次握手。如果打算让双方都做好准备的话，一定要发送三次报文，而且只需要三次报文就可以了。可以想见，如果再加上TCP的超时重传机制，那么TCP就完全可以保证一个数据包被送到目的地。2.结束连接TCP有一个特别的概念叫做half-close，这个概念是说，TCP的连接是全双工(可以同时发送和接收)连接，因此在关闭连接的`时候，必须关闭传和送两个方向上的连接。客户机给服务器一个FIN为1的TCP报文，然后服务器返回给客户端一个确认ACK报文，并且发送一个FIN报文，当客户机回复ACK报文后(四次握手)，连接就结束了。3.最大报文长度在建立连接的时候，通信的双方要互相确认对方的最大报文长度(MSS)，以便通信。一般这个SYN长度是MTU减去固定IP首部和TCP首部长度。对于一个以太网，一般可以达到1460字节。当然如果对于非本地的IP，这个MSS可能就只有536字节，而且，如果中间的传输网络的MSS更加的小的话，这个值还会变得更小。4.客户端应用程序的状态迁移图客户端的状态可以用如下的流程来表示：CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED以上流程是在程序正常的情况下应该有的流程，从书中的图中可以看到，在建立连接时，当客户端收到SYN报文的ACK以后，客户端就打开了数据交互地连接。而结束连接则通常是客户端主动结束的，客户端结束应用程序以后，需要经历FIN_WAIT_1，FIN_WAIT_2等状态，这些状态的迁移就是前面提到的结束连接的四次握手。5.服务器的状态迁移图服务器的状态可以用如下的流程来表示：CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED在建立连接的时候，服务器端是在第三次握手之后才进入数据交互状态，而关闭连接则是在关闭连接的第二次握手以后(注意不是第四次)。而关闭以后还要等待客户端给出最后的ACK包才能进入初始的状态。6.TCP服务器设计前面曾经讲述过UDP的服务器设计，可以发现UDP的服务器完全不需要所谓的并发机制，它只要建立一个数据输入队列就可以。但是TCP不同，TCP服务器对于每一个连接都需要建立一个独立的进程(或者是轻量级的，线程)，来保证对话的独立性。所以TCP服务器是并发的。而且TCP还需要配备一个呼入连接请求队列(UDP服务器也同样不需要)，来为每一个连接请求建立对话进程，这也就是为什么各种TCP服务器都有一个最大连接数的原因。而根据源主机的IP和端口号码，服务器可以很轻松的区别出不同的会话，来进行数据的分发。TCP的交互数据流对于交互性要求比较高的应用，TCP给出两个策略来提高发送效率和减低网络负担：(1)捎带ACK。(2)Nagle算法(一次尽量多的发数据)捎带ACK的发送方式这个策略是说，当主机收到远程主机的TCP数据报之后，通常不马上发送ACK数据报，而是等上一个短暂的时间，如果这段时间里面主机还有发送到远程主机的TCP数据报，那么就把这个ACK数据报“捎带”着发送出去，把本来两个TCP数据报整合成一个发送。一般的，这个时间是200ms。可以明显地看到这个策略可以把TCP数据报的利用率提高很多。Nagle算法上过bbs的人应该都会有感受，就是在网络慢的时候发贴，有时键入一串字符串以后，经过一段时间，客户端“发疯”一样突然回显出很多内容，就好像数据一下子传过来了一样，这就是Nagle算法的作用。Nagle算法是说，当主机A给主机B发送了一个TCP数据报并进入等待主机B的ACK数据报的状态时，TCP的输出缓冲区里面只能有一个TCP数据报，并且，这个数据报不断地收集后来的数据，整合成一个大的数据报，等到B主机的ACK包一到，就把这些数据“一股脑”的发送出去。虽然这样的描述有些不准确，但还算形象和易于理解，我们同样可以体会到这个策略对于低减网络负担的好处。在编写插口程序的时候，可以通过TCP_NODELAY来关闭这个算法。并且，使用这个算法看情况的，比如基于TCP的X窗口协议，如果处理鼠标事件时还是用这个算法，那么“延迟”可就非常大了。 ;

主要特点：面向连接、面向字节流、全双工通信、通信可靠。优缺点：应用场景：要求通信数据可靠时，即 数据要准确无误地传递给对方。如：传输文件：HTTP、HTTPS、FTP等协议；传输邮件：POP、SMTP等协议ps：首部的前 20 个字节固定，后面有 4n 字节根据需要增加。故 TCP首部最小长度 = 20字节（最大60个字节）。TCP报头中的源端口号和目的端口号同IP数据报中的源IP与目的IP唯一确定一条TCP连接。重要字段：客户端与服务器来回共发送三个TCP报文段来建立运输连接，三个TCP报文段分别为：（1）客户端A向服务器B发送的TCP请求报段“SYN=1,seq=x”；（2）服务器B向客户端A发送的TCP确认报文段“SYN=1,ACK=1,seq=y,ack=x+1”；（3）客户端A向服务器B发送的TCP确认报文段“ACK=1,seq=x+1,ack=y+1”。ps：在建立TCP连接之前，客户端和服务器都处于关闭状态（CLOSED）,直到客户端主动打开连接，服务器才被动打开连接（处于监听状态 = LISTEN）,等待客户端的请求。TCP 协议是一个面向连接的、安全可靠的传输层协议，三次握手的机制是为了保证能建立一个安全可靠的连接。通过上述三次握手，双方确认自己与对方的发送与接收是正常的，就建立起一条TCP连接，即可传送应用层数据。ps：因 TCP提供的是全双工通信，故通信双方的应用进程在任何时候都能发送数据；三次握手期间，任何1次未收到对面的回复，则都会重发。为什么两次握手不行呢？结论：防止服务器接收了早已经失效的连接请求报文，服务器同意连接，从而一直等待客户端请求，最终导致形成死锁、浪费资源。ps：SYN洪泛攻击：（具体见下文）为什么不需要四次握手呢？SYN 同步序列编号(Synchronize Sequence Numbers) 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK确认序号标志消息响应。这样在客户机和服务器之间才能建立起可靠的 TCP 连接，数据才可以在客户机和服务器之间传递。如何来解决半连接攻击？如何来解决全连接攻击？请注意，现在 TCP 连接还没有释放掉。必须经过时间等待计时器设置的时间 2MSL（MSL：最长报文段寿命）后，客户端才能进入到 CLOSED 状态，然后撤销传输控制块，结束这次 TCP 连接。当然如果服务器一收到 客户端的确认就进入 CLOSED 状态，然后撤销传输控制块。所以在释放连接时，服务器结束 TCP 连接的时间要早于客户端。TCP是全双工的连接，必须两端同时关闭连接，连接才算真正关闭。简言之，客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器才会发送 FIN 连接释放报文，对方确认后就完全关闭了TCP连接。举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。ps：设想这样一个情景：客户端已主动与服务器建立了 TCP 连接。但后来客户端的主机突然发生故障。显然，服务器以后就不能再收到客户端发来的数据。因此，应当有措施使服务器不要再白白等待下去。这就需要使用TCP的保活计时器。基本原理：tcp11种状态及变迁其实基本包含在正常的三次握手和四次挥手中，除开CLOSING。正常的三次握手包括4中状态变迁：服务器打开监听(LISTEN)->客户端先发起SYN主动连接标识->服务器回复SYN及ACK确认->客户端再确认即三次握手TCP连接成功。这里边涉及四种状态及变迁：正常的四次握手包含6种tcp状态变迁，如主动发起关闭方为客户端：客户端发送FIN进入FIN_WAIT1 -> 服务器发送ACK确认并进入CLOSE_WAIT(被动关闭)状态->客户端收到ACK确认后进入FIN_WAIT2状态 -> 服务器再发送FIN进入LAST_ACK状态 -> 客户端收到服务器的FIN后发送ACK确认进入TIME_WAIT状态 -> 服务器收到ACK确认后进入CLOSED状态断开连接 -> 客户端在等待2MSL的时间如果期间没有收到服务器的相关包，则进入CLOSED状态断开连接。CLOSING状态：连接断开期间，一般是客户端发送一个FIN，然后服务器回复一个ACK，然后服务器发送完数据后再回复一个FIN，当客户端和服务器同时接受到FIN时，客户端和服务器处于CLOSING状态，也就是此时双方都正在关闭同一个连接。在进入CLOSING状态后，只要收到了对方对自己发送的FIN的ACK，收到FIN的ACK确认就进入TIME_WAIT状态，因此，如果RTT(Round Trip Time TCP包的往返延时)处在一个可接受的范围内，发出的FIN会很快被ACK从而进入到TIME_WAIT状态，CLOSING状态持续的时间就特别短，因此很难看到这种状态。我们知道网络层，可以实现两个主机之间的通信。但是这并不具体，因为，真正进行通信的实体是在主机中的进程，是一个主机中的一个进程与另外一个主机中的一个进程在交换数据。IP协议虽然能把数据报文送到目的主机，但是并没有交付给主机的具体应用进程。而端到端的通信才应该是应用进程之间的通信。应用场景：UDP协议比TCP协议的效率更高，TCP协议比UDP协议更加安全可靠。下面主要对数据传输出现错误/无应答/堵塞/超时/重复等问题。注意：TCP丢包：TCP是基于不可靠的网路实现可靠传输，肯定会存在丢包问题。如果在通信过程中，发现缺少数据或者丢包，那边么最大的可能性是程序发送过程或者接受过程中出现问题。总结：为了满足TCP协议不丢包，即保证可靠传输，规定如下：注意：TCP丢包有三方面的原因，一是网络的传输质量不好，二是安全策略，三是服务器性能瓶颈先理解2个基础概念：发送窗口、接收窗口工作原理：注意点：关于滑动窗口的知识点：滑动窗口中的数据类型：ARQ解决的问题：出现差错时，让发送方重传差错数据：即 出错重传类型：流量控制和拥塞控制解决的问题：当接收方来不及接收收到的数据时，可通知发送方降低发送数据的效率：即 速度匹配流量控制：注意：拥塞控制：慢开始与拥塞避免：快重传和快恢复：补充：流量控制和拥塞控制的区别什么情况造成TCP粘包和拆包？解决TCP粘包和拆包的方法：传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。最简单的方式是在应用层模仿传输层TCP的可靠性传输。下面不考虑拥塞处理，可靠UDP的简单设计。https://www.jianshu.com/p/65605622234bhttp://www.open-open.com/lib/view/open1517213611158.htmlhttps://blog.csdn.net/dangzhangjing97/article/details/81008836https://blog.csdn.net/qq_30108237/article/details/107057946https://www.jianshu.com/p/6c73a4585eba

为什么要有三次握手，因为如果只有两次握手，那么第一次：客户端发送一个syn包给服务器，里面有一个随机生成的syn，然后客户端处于syn_send状态第二次：服务端收到客户端发来的syn包之后，确认syn包，也就是生成一个ack=syn+1，然后再自己随机生成一个syn包，即syn+ack包，然后返回给客户端，自己变成syn_recv状态第三次：客户端收到服务端发来的syn+ack包之后，确认ack是正确的之后，返回一个ack=syn+1给服务端，此包发送完毕，客户端进入了ESTABLISHED状态，服务端收到ack包后也进入ESTABLISHED状态。SYN攻击，当第二次握手服务端发送了syn+ack包之后，收到客户端发送的ack之前这段时间的tcp链接成为半连接，此时服务端处于syn_recv状态。当大量客户端随机IP疯狂发送tcp链接请求时，客户端以为是不同用户的请求，所以队列中全是半连接，然后导致服务器宕机，正常请求被丢弃。第一个包发送过程丢失A会周期性超时重传，直到收到B的确认第二个包发送过程丢失B会周期性超时重传，直到收到A的确认第三个包发送过程丢失A发送完数据后单方面进入TCP的ESTABLISHED状态，B还处于半链接：TCP协议为什么需要三次握手？第一次：客户端发送一个fin给服务端表示自己要断开连接了，然后进入fin_wait_1状态第二次：服务端收到fin后，发送一个ack=fin+1给客户端，服务端进入close_wait状态，客户端进入fin_wait_2状态第三次：服务端发送一个fin，用来关闭服务端到客户端的数据传输，服务端进入last_ack状态第四次：客户端收到fin后，进入time_wait状态，然后发送一个ack=fin+1给服务端，服务端确认后进入close状态，完成四次挥手TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。如果要正确的理解四次分手的原理，就需要了解四次分手过程中的状态变化。答案解析：浏览器对并发请求的数目限制是针对域名的，即针对同一域名（包括二级域名）在同一时间支持的并发请求数量的限制。如果请求数目超出限制，则会阻塞。因此，网站中对一些静态资源，使用不同的一级域名，可以提升浏览器并行请求的数目，加速界面资源的获取速度。在 HTTP/1.0 中，一个http请求收到服务器响应后，会断开对应的TCP连接。这样每次请求，都需要重新建立TCP连接，这样一直重复建立和断开的过程，比较耗时。所以为了充分利用TCP连接，可以设置头字段 Connection: keep-alive ，这样http请求完成后，就不会断开当前的TCP连接，后续的http请求可以使用当前TCP连接进行通信。第一次访问有初始化连接和SSL开销初始化连接和SSL开销消失了，说明使用的是同一个TCP连接。HTTP/1.1 将 Connection 写入了标准，默认值为 keep-alive 。除非强制设置为 Connection: close ，才会在请求后断开TCP连接。所以这一题的答案就是：默认情况下建立的TCP连接不会断开，只有在请求头中设置 Connection: close 才会在请求后关闭TCP连接。HTTP/1.1 中，单个TCP连接，在同一时间只能处理一个http请求，虽然存在Pipelining技术支持多个请求同时发送，但由于实践中存在很多问题无法解决，所以浏览器默认是关闭，所以可以认为是不支持同时多个请求。HTTP2 提供了多路传输功能，多个http请求，可以同时在同一个TCP连接中进行传输。页面资源请求时，浏览器会同时和服务器建立多个TCP连接，在同一个TCP连接上顺序处理多个HTTP请求。所以浏览器的并发性就体现在可以建立多个TCP连接，来支持多个http同时请求。Chrome浏览器最多允许对同一个域名Host建立6个TCP连接，不同的浏览器有所区别。补充如果图片都是HTTPS的连接，并且在同一域名下，浏览器会先和服务器协商使用 HTTP2 的 Multiplexing 功能进行多路传输，不过未必所有的挂在这个域名下的资源都会使用同一个TCP连接。如果用不了HTTPS或者HTTP2（HTTP2是在HTTPS上实现的），那么浏览器会就在同一个host建立多个TCP连接，每一个TCP连接进行顺序请求资源。参考：[1]. 第8题-浏览器HTTP请求并发数和TCP连接的关系

如果你在学习这门课程，仅仅为了理解网络工作原理，那么只要了解TCP是可靠传输，数据传输丢失时会重传就可以了。如果你还要参加研究生考试或者公司面试等，那么下面内容很有可能成为考查的知识点，主要的重点是序号/确认号的编码、超时定时器的设置、可靠传输和连接的管理。 1 TCP连接TCP面向连接，在一个应用进程开始向另一个应用进程发送数据之前，这两个进程必须先相互“握手”，即它们必须相互发送某些预备报文段，以建立连接。连接的实质是双方都初始化与连接相关的发送/接收缓冲区，以及许多TCP状态变量。这种“连接”不是一条如电话网络中端到端的电路，因为它们的状态完全保留在两个端系统中。TCP连接提供的是全双工服务 ，应用层数据就可在从进程B流向进程A的同时，也从进程A流向进程B。TCP连接也总是点对点的 ，即在单个发送方与单个接收方之间建立连接。一个客户机进程向服务器进程发送数据时，客户机进程通过套接字传递数据流。客户机操作系统中运行的 TCP软件模块首先将这些数据放到该连接的发送缓存里 ，然后会不时地从发送缓存里取出一块数据发送。TCP可从缓存中取出并放入报文段中发送的数据量受限于最大报文段长MSS，通常由最大链路层帧长度来决定(也就是底层的通信链路决定)。 例如一个链路层帧的最大长度1500字节，除去数据报头部长度20字节，TCP报文段的头部长度20字节，MSS为1460字节。报文段被往下传给网络层，网络层将其封装在网络层IP数据报中。然后这些数据报被发送到网络中。当TCP在另一端接收到一个报文段后，该报文段的数据就被放人该连接的接收缓存中。应用程序从接收缓存中读取数据流(注意是应用程序来读，不是操作系统推送)。TCP连接的每一端都有各自的发送缓存和接收缓存。因此TCP连接的组成包括:主机上的缓存、控制变量和与一个进程连接的套接字变量名，以及另一台主机上的一套缓存、控制变量和与一个进程连接的套接字。在这两台主机之间的路由器、交换机中，没有为该连接分配任何缓存和控制变量。2报文段结构TCP报文段由首部字段和一个数据字段组成。数据字段包含有应用层数据。由于MSS限制了报文段数据字段的最大长度。当TCP发送一个大文件时，TCP通常是将文件划分成长度为MSS的若干块。TCP报文段的结构。首部包括源端口号和目的端口号，它用于多路复用/多路分解来自或送至上层应用的数据。另外，TCP首部也包括校验和字段。报文段首部还包含下列字段:32比特的序号字段和32比特的确认号字段。这些字段被TCP发送方和接收方用来实现可靠数据传输服务。16比特的接收窗口字段，该字段用于流量控制。该字段用于指示接收方能够接受的字节数量。4比特的首部长度字段,该字段指示以32比特的字为单位的TCP首部长度。一般TCP首部的长度就是20字节。可选与变长的选项字段,该字段用于当发送方与接收方协商最大报文段长度，或在高速网络环境下用作窗口调节因子时使用。标志字段ACK比特用于指示确认字段中的ACK值的有效性，即该报文段包括一个对已被成功接收报文段的确认。 SYN和FIN比特用于连接建立和拆除。 PSH、URG和紧急指针字段通常没有使用。•序号和确认号TCP报文段首部两个最重要的字段是序号字段和确认号字段。TCP把数据看成一个无结构的但是有序的字节流。TCP序号是建立在传送的字节流之上，而不是建立在传送的报文段的序列之上。一个报文段的序号是该报文段首字节在字节流中的编号。例如，假设主机A上的一个进程想通过一条TCP连接向主机B上的一个进程发送一个数据流。主机A中的TCP将对数据流中的每一个字节进行编号。假定数据流由一个包含4500字节的文件组成(可以理解为应用程序调用send函数传递过来的数据长度)，MSS为1000字节(链路层一次能够传输的字节数)，如果主机决定数据流的首字节编号是7。TCP模块将为该数据流构建5个报文段(也就是分5个IP数据报)。第一个报文段的序号被赋为7;第二个报文段的序号被赋为1007,第三个报文段的序号被赋为2007，以此类推。前面4个报文段的长度是1000，最后一个是500。确认号要比序号难理解一些。前面讲过，TCP是全双工的，因此主机A在向主机B发送数据的同时，也可能接收来自主机B的数据。从主机B到达的每个报文段中的序号字段包含了从B流向A的数据的起始位置。 因此主机B填充进报文段的确认号是主机B期望从主机A收到的下一报文段首字节的序号。假设主机B已收到了来自主机A编号为7-1006的所有字节，同时假设它要发送一个报文段给主机A。主机B等待主机A的数据流中字节1007及后续所有字节。所以，主机B会在它发往主机A的报文段的确认号字段中填上1007。再举一个例子，假设主机B已收到一个来自主机A的包含字节7-1006的报文段，以及另一个包含字节2007-3006的报文段。由于某种原因，主机A还没有收到字节1007-2006的报文段。在这个例子中，主机A为了重组主机B的数据流，仍在等待字节1007。因此，A在收到包含字节2007-3006的报文段时，将会又一次在确认号字段中包含1007。 因为TCP只确认数据流中至第一个丢失报文段之前的字节数据，所以TCP被称为是采用累积确认。TCP的实现有两个基本的选择:1接收方立即丢弃失序报文段;2接收方保留失序的字节，并等待缺少的字节以填补该间隔。一条TCP连接的双方均可随机地选择初始序号。 这样做可以减少将那些仍在网络中的来自两台主机之间先前连接的报文段，误认为是新建连接所产生的有效报文段的可能性。•例子telnetTelnet由是一个用于远程登录的应用层协议。它运行在TCP之上，被设计成可在任意一对主机之间工作。假设主机A发起一个与主机B的Telnet会话。因为是主机A发起该会话，因此主机A被标记为客户机，主机B被标记为服务器。用户键入的每个字符(在客户机端)都会被发送至远程主机。远程主机收到后会复制一个相同的字符发回客户机，并显示在Telnet用户的屏幕上。这种“回显”用于确保由用户发送的字符已经被远程主机收到并处理。因此，在从用户击键到字符显示在用户屏幕上之间的这段时间内，每个字符在网络中传输了两次。现在假设用户输入了一个字符“C”，假设客户机和服务器的起始序号分别是42和79。前面讲过，一个报文段的序号就是该报文段数据字段首字节的序号。因此，客户机发送的第一个报文段的序号为42，服务器发送的第一个报文段的序号为79。前面讲过，确认号就是主机期待的数据的下一个字节序号。在TCP连接建立后但没有发送任何数据之前，客户机等待字节79，而服务器等待字节42。如图所示，共发了3个报文段。第一个报文段是由客户机发往服务器，其数据字段里包含一字节的字符“C”的ASCII码，其序号字段里是42。另外，由于客户机还没有接收到来自服务器的任何数据，因此该报文段中的确认号字段里是79。第二个报文段是由服务器发往客户机。它有两个目的:第一个目的是为服务器所收到的数据提供确认。服务器通过在确认号字段中填入43，告诉客户机它已经成功地收到字节42及以前的所有字节，现在正等待着字节43的出现。第二个目的是回显字符“C”。因此，在第二个报文段的数据字段里填入的是字符“C”的ASCII码，第二个报文段的序号为79，它是该TCP连接上从服务器到客户机的数据流的起始序号，也是服务器要发送的第一个字节的数据。这里客户机到服务器的数据的确认被装载在一个服务器到客户机的数据的报文段中，这种确认被称为是捎带确认.第三个报文段是从客户机发往服务器的。它的唯一目的是确认已从服务器收到的数据。3往返时延的估计与超时TCP如同前面所讲的rdt协议一样，采用超时/重传机制来处理报文段的丢失问题。最重要的一个问题就是超时间隔长度的设置。显然，超时间隔必须大于TCP连接的往返时延RTT，即从一个报文段发出到收到其确认时。否则会造成不必要的重传。•估计往返时延TCP估计发送方与接收方之间的往返时延是通过采集报文段的样本RTT来实现的，就是从某报文段被发出到对该报文段的确认被收到之间的时间长度。也就是说TCP为一个已发送的但目前尚未被确认的报文段估计sampleRTT，从而产生一个接近每个RTT的采样值。但是，TCP不会为重传的报文段计算RTT。为了估计一个典型的RTT，采取了某种对RTT取平均值的办法。TCP据下列公式来更新EstimatedRTT=(1-)*EstimatedRTT+*SampleRTT即估计RTT的新值是由以前估计的RTT值与sampleRTT新值加权组合而成的。参考值是a=0.125，因此是一个加权平均值。显然这个加权平均对最新样本赋予的权值要大于对老样本赋予的权值。因为越新的样本能更好地反映出网络当前的拥塞情况。从统计学观点来讲，这种平均被称为指数加权移动平均除了估算RTT外，还需要测量RTT的变化，RTT偏差的程度，因为直接使用平均值设置计时器会有问题(太灵敏)。DevRTT=(1-β)*DevRTT+β*|SampleRTT-EstimatedRTT|RTT偏差也使用了指数加权移动平均。B取值0.25.•设置和管理重传超时间隔假设已经得到了估计RTT值和RTT偏差值，那么TCP超时间隔应该用什么值呢?TCP将超时间隔设置成大于等于估计RTT值和4倍的RTT偏差值,否则将造成不必要的重传。但是超时间隔也不应该比估计RTT值大太多，否则当报文段丢失时，TCP不能很快地重传该报文段，从而将给上层应用带来很大的数据传输时延。因此，要求将超时间隔设为估计RTT值加上一定余量。当估计RTT值波动较大时，这个余最应该大些;当波动比较小时，这个余量应该小些。因此使用4倍的偏差值来设置重传时间。TimeoutInterval=EstimatedRTT+4*DevRTT4可信数据传输因特网的网络层服务是不可靠的。IP不保证数据报的交付，不保证数据报的按序交付，也不保证数据报中数据的完整性。TCP在IP不可靠的尽力而为服务基础上建立了一种可靠数据传输服务。TCP提供可靠数据传输的方法涉及前面学过的许多原理。TCP采用流水线协议、累计确认。TCP推荐的定时器管理过程使用单一的重传定时器，即使有多个已发送但还未被确认的报文段也一样。重传由超时和多个ACK触发。在TCP发送方有3种与发送和重传有关的主要事件:从上层应用程序接收数据，定时器超时和收到确认ACK。从上层应用程序接收数据。一旦这个事件发生，TCP就从应用程序接收数据，将数据封装在一个报文段中，并将该报文段交给IP。注意到每一个报文段都包含一个序号，这个序号就是该报文段第一个数据字节的字节流编号。如果定时器还没有计时，则当报文段被传给IP时，TCP就启动一个该定时器。第二个事件是超时。TCP通过重传引起超时的报文段来响应超时事件。然后TCP重启定时器。第三个事件是一个来自接收方的确认报文段(ACK)。当该事件发生时，TCP将ACK的值y与变量SendBase(发送窗口的基地址)进行比较。TCP状态变量SendBase是最早未被确认的字节的序号。就是指接收方已正确按序接收到数据的最后一个字节的序号。TCP采用累积确认，所以y确认了字节编号在y之前的所有字节都已经收到。如果Y>SendBase,则该ACK是在确认一个或多个先前未被确认的报文段。因此发送方更新其SendBase变量，相当于发送窗口向前移动。另外，如果当前有未被确认的报文段，TCP还要重新启动定时器。快速重传超时触发重传存在的另一个问题是超时周期可能相对较长。当一个报文段丢失时，这种长超时周期迫使发送方等待很长时间才重传丢失的分组，因而增加了端到端时延。所以通常发送方可在超时事件发生之前通过观察冗余ACK来检测丢包情况。冗余ACK就是接收方再次确认某个报文段的ACK，而发送方先前已经收到对该报文段的确认。当TCP接收方收到一个序号比所期望的序号大的报文段时，它认为检测到了数据流中的一个间隔，即有报文段丢失。这个间隔可能是由于在网络中报文段丢失或重新排序造成的。因为TCP使用累计确认，所以接收方不向发送方发回否定确认，而是对最后一个正确接收报文段进行重复确认(即产生一个冗余ACK)如果TCP发送方接收到对相同报文段的3个冗余ACK.它就认为跟在这个已被确认过3次的报文段之后的报文段已经丢失。一旦收到3个冗余ACK，TCP就执行快速重传 ，即在该报文段的定时器过期之前重传丢失的报文段。5流量控制前面讲过，一条TCP连接双方的主机都为该连接设置了接收缓存。当该TCP连接收到正确、按序的字节后，它就将数据放入接收缓存。相关联的应用进程会从该缓存中读取数据，但没必要数据刚一到达就立即读取。事实上，接收方应用也许正忙于其他任务，甚至要过很长时间后才去读取该数据。如果应用程序读取数据时相当缓慢，而发送方发送数据太多、太快，会很容易使这个连接的接收缓存溢出。TCP为应用程序提供了流量控制服务以消除发送方导致接收方缓存溢出的可能性。因此，可以说 流量控制是一个速度匹配服务，即发送方的发送速率与接收方应用程序的读速率相匹配。前面提到过，TCP发送方也可能因为IP网络的拥塞而被限制，这种形式的发送方的控制被称为拥塞控制(congestioncontrol)。TCP通过让接收方维护一个称为接收窗口的变量来提供流量控制。接收窗口用于告诉发送方，该接收方还有多少可用的缓存空间。因为TCP是全双工通信，在连接两端的发送方都各自维护一个接收窗口变量。 主机把当前的空闲接收缓存大小值放入它发给对方主机的报文段接收窗口字段中，通知对方它在该连接的缓存中还有多少可用空间。6 TCP连接管理客户机中的TCP会用以下方式与服务器建立一条TCP连接:第一步: 客户机端首先向服务器发送一个SNY比特被置为1报文段。该报文段中不包含应用层数据，这个特殊报文段被称为SYN报文段。另外，客户机会选择一个起始序号，并将其放置到报文段的序号字段中。为了避免某些安全性攻击，这里一般随机选择序号。第二步: 一旦包含TCP报文段的用户数据报到达服务器主机，服务器会从该数据报中提取出TCPSYN报文段，为该TCP连接分配TCP缓存和控制变量，并向客户机TCP发送允许连接的报文段。这个允许连接的报文段还是不包含应用层数据。但是，在报文段的首部却包含3个重要的信息。首先，SYN比特被置为1。其次，该 TCP报文段首部的确认号字段被置为客户端序号+1最后，服务器选择自己的初始序号，并将其放置到TCP报文段首部的序号字段中。 这个允许连接的报文段实际上表明了:“我收到了你要求建立连接的、带有初始序号的分组。我同意建立该连接，我自己的初始序号是XX”。这个同意连接的报文段通常被称为SYN+ACK报文段。第三步: 在收到SYN+ACK报文段后，客户机也要给该连接分配缓存和控制变量。客户机主机还会向服务器发送另外一个报文段，这个报文段对服务器允许连接的报文段进行了确认。因为连接已经建立了，所以该ACK比特被置为1，称为ACK报文段，可以携带数据。一旦以上3步完成，客户机和服务器就可以相互发送含有数据的报文段了。为了建立连接，在两台主机之间发送了3个分组，这种连接建立过程通常被称为 三次握手(SNY、SYN+ACK、ACK，ACK报文段可以携带数据) 。这个过程发生在客户机connect()服务器，服务器accept()客户连接的阶段。假设客户机应用程序决定要关闭该连接。(注意，服务器也能选择关闭该连接)客户机发送一个FIN比特被置为1的TCP报文段，并进人FINWAIT1状态。当处在FINWAIT1状态时，客户机TCP等待一个来自服务器的带有ACK确认信息的TCP报文段。当它收到该报文段时，客户机TCP进入FINWAIT2状态。当处在FINWAIT2状态时，客户机等待来自服务器的FIN比特被置为1的另一个报文段，收到该报文段后，客户机TCP对服务器的报文段进行ACK确认，并进入TIME_WAIT状态。TIME_WAIT状态使得TCP客户机重传最终确认报文，以防该ACK丢失。在TIME_WAIT状态中所消耗的时间是与具体实现有关的，一般是30秒或更多时间。 经过等待后，连接正式关闭，客户机端所有与连接有关的资源将被释放。 因此TCP连接的关闭需要客户端和服务器端互相交换连接关闭的FIN、ACK置位报文段。