tcp连接点(查看tcp连接的命令)

TCP是因特网中的传输层协议，使用三次握手协议建立连接。当主动方发出SYN连接请求后，等待对方回答 TCP的三次握手SYN+ACK，并最终对对方的 SYN 执行 ACK 确认。这种建立连接的方法可以防止产生错误的连接，TCP使用的流量控制协议是可变大小的滑动窗口协议。TCP三次握手的过程如下：客户端发送SYN（SEQ=x）报文给服务器端，进入SYN_SEND状态。服务器端收到SYN报文，回应一个SYN （SEQ=y）ACK(ACK=x+1）报文，进入SYN_RECV状态。客户端收到服务器端的SYN报文，回应一个ACK(ACK=y+1）报文，进入Established状态。 三次握手完成，TCP客户端和服务器端成功地建立连接，可以开始传输数据了。
首先纠正你一点。。不是连接方式。。是数据的交换方式。。 TCP属于分组交换方式。。
TCP/IP(Transmission Control Protocol/Internet Protocol) 即传输控制协议/网间协议,是一个工业标准的协议集,它是为广域网(WANs)设计的。它是由ARPANET网的研究机构发展起来的。 有时我们将TCP/IP描述为互联网协议集"Internet Protocol Suite",TCP和IP是其中的两个协议(后面将会介绍)。由于TCP和IP是大家熟悉的协议,以至于用TCP/IP或IP/TCP这个词代替了整个协议集。这尽管有点奇怪,但没有必要去争论这个习惯。例如,有时我们讨论NFS 是基于TCP/IP时,尽管它根本没用到TCP(只用到IP,和另一种交互式 协议UDP而不是TCP)。Internet是网络的集合,包括ARPANET、NSFNET、分布在各地的局域网、以及其它类型的网络,如(DDN,Defense Data Network美国国防数据网络),这些统称为Internet。所有这些大大小小的网络互联在一起。(因为大多数网络基本协议是由DDN组织开发的,所以以前有时DDN与Internet在某种意义上具有相同的含义)。网络上的用户可以互相传送信息,除一些有授权限制和安全考虑外。一般的讲,互联网协议文档案是Internet委员会自己采纳的基本标准。 TCP/IP标准与其说由委员会指定,倒不如说由"舆论"来开发的。 任何人都可以提供一个文档,以RFC(Request for Comment需求注释) 方式公布。TCP/IP的标准在一系列称为RFC的文档中公布。文档由技术专家、特别工作组、或RFC编辑修订。公布一个文档时,该文档被赋予一个RFC量,如RFC959说明FTP、RFC793说明TCP、RFC791说明IP等。 最初的RFC一直保留而从来不会被更新,如果修改了该文档,则该文档又以一个新号码公布。因此,重要的是要确认你拥有了关于某个专题的最新RFC文档。文后会列出主要的RFC文档号。不管怎样,TCP/IP是一个协议集。为应用提供一些"低级"功能,这些包括IP、TCP、UDP。其它是执行特定任务的应用协议,如计算机间传送文件、发送电子邮件、或找出谁注册到另外一台计算机。因此, 最重要的"商业"TCP/IP服务有:* 文件传送File Transfer。文件传送协议FTP(File Transfer Protocol)允许用户从一台计算机到另一台取得文件,或发送文件到另外一台计算机。从安全性方面考虑,需要用户指定一个使用其它计算机的用户名和口令。它不同与NFS(Network File System)和Netbios协议。一旦你要访问另一台 系统中的文件,任何时刻都要运行FTP。而且你只能拷贝文件到自己的机器中去来使用它。(RFC 959中关于FTP的说明)* 远程登录Remote login网络终端协议TELNET允许用户登录到网络上任一计算机上。你可启动一个远程进程连接到指定的计算机,直到进程结束,期间你所键入的内容被送到所指定的计算机。值得注意的是,这时你实际上是与你的计算机进行对话。TELENET程序使得你的计算机在整个过程中不见了,所敲的每一个字符直接送到所登录的计算机系统。一般的说,这种远程连接是通过类式拨号连接的,也就是,拨通后,远程系统提示你输入注册名和口令,退出远程系统,TELNET程序也就退出,你又与自己的计算机对话了。微电脑中的TELNET工具一般含有一个终端仿真程序。* 计算机邮件Mail允许你发送消息给其它计算机的用户。通常,人们趋向于使用指定的一台或两台计算机。计算机邮件系统只需你简单地往另一用户的邮件文件中添加信息,但随之产生问题,使用的微电脑的环境不同,还有重要的是宏(MICRO)不适合于接受计算机邮件。为了发送电子邮件,邮件软件希望连接到目的计算机,如果是微电脑,也许它已关机,或者正在运行另一个应用程序呢?出于这种原因,通常由一个较大的系统来处理这些邮件,也就是一个一直运行着的邮件服务器。邮件软件成为用户从邮件服务器取回邮件的一个界面。任何一个的TCP/IP工具提供上述这些服务。这些传统的应用功能在基于TCP/IP的网络中一直扮演非常重要的角色。目前情况有点变化,这些功能使用也发生变化,如老系统的改造,计算机的发展等,出现了各种安装版本,如:微电脑、工作站、小型机、和巨型机等。这些计算机好象在一起完成指定的任务,尽管有时看来像是只用到某个指定 的计算机,但它是通过网络得到其它计算机系统的服务。服务器Server是为网络上其它提供指定服务的系统,客户Client是得到这种服务的另外计算机系统。(值得注意的是,服务/客户机不一定是不同的计算机,有可能是同一计算机中的不同运行程序)。以下是几种目前计算机上典型的一些服务,这些服务可在TCP/IP网络上调用。* 网络文件系统(NFS)这种访问另一计算机的文件的方法非常接近于流行的FTP。网络文件系统提供磁盘或设备服务,而无需特定的网络实用程序来访问另一系统的文件。可以简单地认为它是一个外加的磁盘驱动器。这种额外"虚拟"磁盘驱动器就是其它计算机系统的磁盘。这非常有用。你只需加大几台计算机的磁盘容量,就可使网络上其他用户访问它,且不说所带来的经济效益,它还能够让几台工作的计算机共享相同的文件。它也使得系统维护和备份易如反掌,因为再不必为大量的不同机器上 的文件的升级和备份而担心。* 远程打印(Remote printing)允许你使用其它计算机上的打印机,好象这些打印机直接连到你的计算机上。* 远程执行(Remote execution)允许你请求运行在不同计算机上的特殊程序。当你在一个很小的计算机上运行一个需要大机系统资源的程序时,这时候远程执行非常有用。* 名字服务器(Name servers)在一个大的系统安装过程中,需要用到大量的各种名字,包括用户名、口令,姓名、网络地址、帐号等,管理这些是非常令人乏味的。因此将这些数据形成数据库,放到一个小系统中去,其它系统通过网络来访问这些数据。* 终端服务器(Terminal servers)很多的终端连接安装不再直接将终端连到计算机,取而代之的是,将他们连接到终端服务器上。终端服务器是一个小的计算机,它只需知道怎样运行TELNET(或其它一些完成远程登录的协议)。如果你的终端想连上去,只用键入要连的计算机名就可。通常有可能同时有几个这种连接,这时终端服务器采用快速开关技术来切换。 上述所描述的一些协议是由Berkeley, Sun,或其它组织定义的。因此,它们不是互联网协议集(Internet Protocol Suite)的一部分, 只是使用到TCP/IP的工具,如同一般的TCP/IP 应用协议。因为协议的定义不一致,并且商业支持的TCP/IP工具广泛应用,也许会把这些协议作为互联协议集中的一部分。上述列出的只是基于TCP/IP部分服务的一些简单例子,但包含了一些"主要"的应用。

TCP即传输控制协议。TCP连接是互联网连接协议集的一种。TCP通信最重要的特征是：有序和可靠。有序通过将文本流分段并编号实现,可靠通过ACK回复和重复发送实现。TCP连接状态图参考文章:TCP连接过程详解blog.163.com/hlz_2599/blog/static/142378474201151943414397/
TCP/IP(Transmission Control Protocol/Internet Protocol) 即传输控制协议/网间协议,是一个工业标准的协议集,它是为广域网(WAN)设计的。它是由ARPANET网的研究机构发展起来的。 　　有时我们将TCP/IP描述为互联网协议集"InternetProtocolSuite",TCP和IP是其中的两个协议(后面将会介绍)。由于TCP和IP是大家熟悉的协议,以至于用TCP/IP或IP/TCP这个词代替了整个协议集。这尽管有点奇怪,但没有必要去争论这个习惯。例如,有时我们讨论NFS是基于TCP/IP时,尽管它根本没用到TCP(只用到IP,和另一种交互式 协议UDP而不是TCP)。 　　TCP/IP的标准在一系列称为RFC的文档中公布。文档由技术专家、特别工作组、或RFC编辑修订。公布一个文档时,该文档被赋予一个RFC编号,如RFC959（FTP的说明文档）、RFC793（TCP的说明文档）、RFC791（IP的说明文档）等。最初的RFC一直保留而从来不会被更新,如果修改了该文档,则该文档又以一个新号码公布。因此,重要的是要确认你拥有了关于某个专题的最新RFC文档。通常在RFC的开头部分，有相关RFC的更新(update)、修改(errata)、作废（obsolete）信息，提示读者信息的时效性。
TCP/IP(Transmission Control Protocol/Internet Protocol) 即传输控制协议/网间协议,是一个工业标准的协议集,它是为广域网(WAN)设计的

TCP是面向连接的协议。运输连接是用来传送TCP报文的。TCP运输连接的建立和释放是每一次连接通信过程中必不可少的。因此，运输连接就有三个阶段：连接建立，数据传送和连接释放。需要解决以下3个问题：连接建立这个过程，需要在客户端和服务器之间，交换3个TCP报文段，也就是三次握手????x3。????请注意，在本例中，A主动打开连接，B被动打开连接一开始，B就在准备接受客户进程的连接请求，然后服务器进程就处于 LISTEN （收听）状态，等待客户的连接请求。如有，即作出响应。A的TCP客户进程像B发出连接请求报文段，这时，首部中的同步位SYN = 1，同时选择一个初始序号 seq = x 。TCP规定????，SYN报文段不能携带数据，但要消耗掉一个序号。这时，TCP客户进程进入SYN-SENT（同步已发送）状态。B收到连接请求的报文段后，如同意建立连接，则向A发送确认。在确认报文段中，应把SYN位和ASK位都置1，确认号是 ack = x + 1 ，同时也为自己选择一个初始序号 seq = y 。请注意，这个报文段也不能携带数据。但同样要消耗掉一个序号。这时，TCP服务器进程进入SYN-RCVD（同步收到）状态。TCP客户进程收到B的确认后，还要向B给出确认。确认报文段的ACK置1，确认号 ack = y + 1 ，而自己的序号 seq = x + 1 。TCP的标准规定????，ACK报文段可以携带数据。但如果不携带数据则不消耗序号，在这种情况下，下一个数据报文段的序号仍是 seq = x +1 。这时，TCP连接已经建立????，A进入ESTABLISHED（已建立连接）状态。当B收到A的确认后，也进入ESTABLISHED（已建立连接）???? Q:为什么A最后还有发送一次确认呢？????A:主要是为了防止已失效的连接请求报文段突然又传送到B，因而产生错误。所谓“已失效的连接请求报文段”是这样产生的。????考虑一种正常情况，A 发出连接请求????，但因连接请求报文丢失而未收到确认。于是A再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。A共发出了两个连接请求的报文段，其中第一个丢失????，第二个到达了B????，没有“已失效的连接请求报文段”。????现假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某个网络节点长时间的滞留????，以至延误到连接释放以后的某个时间才到达B。本来这是一个 早已失效的报文段 ，但是B收到此时小的连接请求的报文段之后，误以为是A又发出一次新的连接请求。于是向A发出确认报文段，同意建立连接。假定不采用报文握手。那么只要B发出确认之后，新的连接就建立了。由于现在A并没有发出建立连接的请求，因此不会理睬B的确认????，也不会向B发送数据，但B确以为新的运输连接已经建立，并一直等待A发来的数据。B的许多资源就这样白白浪费了。

在TCP／IP中，TCP协议通过三次握手来建立连接，从而提供可靠的连接服务。第一次握手：建立连接后，客户端向服务器发送syn包（syn＝j），进入SYN＿SEND状态，等待服务器确认；第二次握手：当服务器收到syn包时，必须确认客户端的syn（ack＝j＋1）并发送一个syn包（syn＝k），即syn＋ack包。此时，服务器进入SYN＿RECV状态。第三次握手：SYN＋ACK包，客户端收到服务器端发来的确认包ACK（ACK＝k＋1），来发送这个包来发送，客户端和服务器端进入建立状态，完成三路握手。扩展资料：重要概念：无关的队列：三重握手协议、服务器维护一个独立队列，为每个客户的SYN包创建一个条目（SYN＝j）表明服务器已经收到了SYN包和确认发送到客户，等待客户的确认包。这些条目标识的连接处于服务器的Syn＿RECV状态，当服务器接收到客户机的确认包时，它将删除该条目，服务器将进入已建立的状态。Backlog参数：表示要保持的未连接队列的最大数量。当服务器发送synack包时，如果没有收到客户端确认包，服务器将进行第一次重传，等待一段时间仍然没有收到客户端确认包，然后进行第二次重传。如果重传号超过系统指定的最大重传号，系统将从半连接队列中删除连接信息。注意每个重传的等待时间可能不相同。半连接生存时间：指半连接队列中条目的最长生存时间，即从接收SYN包到确认无效消息的最长服务时间。这个时间值是所有重传请求包的最长等待时间的总和。有时我们也称半连接生存时间为超时时间，SYN＿RECV生存时间。
在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。 第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。完成三次握手，客户端与服务器开始传送数据，在上述过程中，还有一些重要的概念：未连接队列：在三次握手协议中，服务器维护一个未连接队列，该队列为每个客户端的SYN包（syn=j）开设一个条目，该条目表明服务器已收到SYN包，并向客户发出确认，正在等待客户的确认包。这些条目所标识的连接在服务器处于Syn_RECV状态，当服务器收到客户的确认包时，删除该条目，服务器进入ESTABLISHED状态。Backlog参数：表示未连接队列的最大容纳数目。SYN-ACK 重传次数 服务器发送完SYN－ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。注意，每次重传等待的时间不一定相同。 半连接存活时间：是指半连接队列的条目存活的最长时间，也即服务从收到SYN包到确认这个报文无效的最长时间，该时间值是所有重传请求包的最长等待时间总和。有时我们也称半连接存活时间为Timeout时间、SYN_RECV存活时间。

title: TCP 总结date: 2018-03-25 09:40:24tags:categories:-计算机网络我们都知道 TCP 是位于传输层的协议，他还有一个兄弟就是 UDP ，他们两共同构成了传输层。显然他们之间有很大的区别要不然的话在传输层只需要一个就好了。其中最重要的区别就是一个面向连接另外一个不是，这个区别就导致了他们是否能够保证稳定传输，显然不面向连接的 UDP 是没办法保证可靠传输的，他只能靠底层的网络层和链路层来保证。我们都知道网络层采用的是不可靠的 IP 协议。好吧，网络层也保证不了可靠传输，所以 UDP 保证可靠传输只能依靠链路层了。而 TCP 就好说了他不仅仅有底层的链路层的支持，还有自己的面向链接服务来保证可靠传输。当然 TCP也不仅仅就是比 UDP 多了一个可靠传输，前面也说到了这只是他们之间一个重要的区别。其实他的三个重要特性就是它们之间的区别。* 可靠传输* 流量控制* 拥塞控制TCP 主要是 确认重传机制 数据校验 数据合理分片和排序 流量控制 拥塞控制 依靠来完成可靠传输的 , 下面详细介绍这几种保证可靠传输的方式。确认重传，简单来说就是接收方收到报文以后给发送方一个 ACK 回复，说明自己已经收到了发送方发过来的数据。如果发送方等待了一个特定的时间还没有收到接收方的 ACK 他就认为数据包丢了，接收方没有收到就会重发这个数据包。好的，上面的机制还是比较好理解的，但是我们会发现一个问题，那就是如果接收方已经收到了数据然后返回的 ACK 丢失，发送方就会误判导致重发。而此时接收方就会收到冗余的数据，但是接收方怎么能判定这个数据是冗余的还是新的数据呢？这就涉及到了 TCP 的另外一个机制就是采用序号和确认号，也就是每次发送数据的时候这个报文段里面包括了当前报文段的序号和对上面的报文的确认号，这样我们的接收方可以根据自己接受缓存中已经有的数据来确定是否接受到了重复的报文段。这时候如果出现上面所说的 ACK 丢失，导致接受重复的报文段时客户端丢弃这个冗余的报文段。好现在我们大致了解了确认重传机制，但是还有些东西还没有弄清楚，也就是 TCP 真正的实现究竟是怎样的。这就是我们要解决的第一个问题就是如何确认。这里涉及到两种确认方式，分别称为 累计确认（捎带确认）和单停等协议。用一张图来快速理解，就是每发送一次数据，就进行一次确认。等发送方收到了 ACK 才能进行下一次的发送。一样的也是采用的 ACK 机制，但是注意一点的是，并非对于每一个报文段都进行确认，而仅仅对最后一个报文段确认，捎带的确认了上图中的 203 号及以前的报文。总结：从上面可以看到累计确认的效率更加高，首先他的确认包少一些那么也就是在网络中出现的大部分是需要传输的数据，而不是一半的数据一半的 ACK ，然后我们在第二张图中可以看到我们是可以连续发送多个报文段的（究竟一次性能发多少这个取决于发送窗口，而发送窗口又是由接受窗口和拥塞窗口一起来决定的。），一次性发多个数据会提高网络的吞吐量以及效率这个可以证明，比较简单这里不再赘述！结论：显然怎么看都是后者比较有优势，TCP 的实现者自然也是采用的累计确认的方式！上文中的那个特定的时间就是超时时间，为什么有这个值呢? 其实在发送端发送的时候就为数据启动了一个定时器，这个定时器的初始值就是超时时间。超时时间的计算其实有点麻烦，主要是我们很难确定一个确定的值，太长则进行了无意义的等待，太短就会导致冗余的包。TCP 的设计者们设计了一个计算超时时间的公式，这个公式概念比较多，有一点点麻烦，不过没关系我们一点点的来。首先我们自己思考如何设计一个超时时间的计算公式，超时时间一般肯定是和数据的传输时间有关系的，他必然要大于数据的往返时间（数据在发送端接收端往返一趟所用的时间）。好，那么我们就从往返时间下手，可是又有一个问题就是往返时间并不是固定的我们有如何确定这个值呢？自然我们会想到我们可以取一小段时间的往返时间的平均值来代表这一时间点的往返时间，也就是微积分的思想！好了我们找到了往返时间（RTT），接下来的超时时间应该就是往返时间再加上一个数就能得到超时时间了。这个数也应该是动态的，我们就选定为往返时间的波动差值，也就是相邻两个往返时间的差。下面给出我们所预估的超时时间（TimeOut）公式：很好，看到这里其实你已经差不多理解了超时时间的计算方式了，只不过我们这个公式不够完善，但是思路是对的。我们这时候来看看 TCP 的实现者们采用的方式。好的，这就是 TCP 实现的超时时间的方式，但是在实际的应用中并不是一直采用的这种方式。假如说我们现在网络状态非常的差，一直在丢包我们根本没必要这样计算，而是采用直接把原来的超时时间加倍作为新的超时时间。总结：好的现在我们知道了在两种情况下的超时时间的计算方式，正常的情况下我们采用的上面的比较复杂的计算公式，也就是RTT+波动值否则直接加倍上面我们看到在发送方等待一个超时重传时间后会开始重传，但是我们计算的超时重传时间也不定就很准，也就是说我们经常干的一件事就会是等待，而且一般等的时间还挺长。那么可不可以优化一下呢？当然，在 TCP 实现中是做了优化的，也就是这里说到的快速重传机制。他的原理就是在发送方收到三个冗余的 ACK 的时候，就开始重传那个报文段。那么为什么是三个冗余的 ACK 呢？注意三个冗余的 ACK 其实是四个 ACK 。我们先了解一下发送 ACK 策略，这个是RFC 5681 文档规定的。好的，那么现在我们可以看到如果出现了三个冗余的 ACK 他只可能是发生了两次情况三，也就是发送了两个比期望值大的数据。但是注意出现情况三有两种可能，一个是丢包，另外一个是乱序到达。比如说我们现在是数据乱序到达的，我们来看一下。第一种乱序情况另外一种乱序丢包情况结论: 很显然我们可以看到，如果发生了乱序有可能会出现三次冗余 ACK，但是如果发现了丢包必然会有三次冗余 ACK 发生，只是 ACK 数量可能更多但是不会比三次少在我们发现丢包以后我们需要重传，但是我们重传的方式也有两种方式可以选择分别是GBN和SR翻译过来就是拉回重传和选择重传。好其实我们已经能从名字上面看出来他们的作用方式了，拉回重传就是哪个地方没收到那么就从那个地方及以后的数据都重新传输，这个实现起来确实很简单，就是把发送窗口和接受窗口移回去，但是同样的我们发现这个方式不实用干了很多重复的事，效率低。那么选择重传就是你想到的谁丢了，就传谁。不存在做无用功的情况。结论:TCP 实际上使用的是两者的结合，称为选择确认，也就是允许 TCP 接收方有选择的确认失序的报文段，而不是累计确认最后一个正确接受的有序报文段。也就是跳过重传那些已经正确接受的乱序报文段。数据校验，其实这个比较简单就是头部的一个校验，然后进行数据校验的时候计算一遍 checkSum 比对一下。在 UDP 中，UDP 是直接把应用层的数据往对方的端口上 “扔” ，他基本没有任何的处理。所以说他发给网络层的数据如果大于1500字节,也就是大于MTU。这个时候发送方 IP 层就需要分片。把数据报分成若干片，使每一片都小于MTU.而接收方IP层则需要进行数据报的重组。这样就会多做许多事情,而更严重的是 ，由于UDP的特性,当某一片数据传送中丢失时 ， 接收方便无法重组数据报，将导致丢弃整个UDP数据报。而在 TCP 中会按MTU合理分片，也就是在 TCP 中有一个概念叫做最大报文段长度（MSS）它规定了 TCP 的报文段的最大长度，注意这个不包括 TCP 的头，也就是他的典型值就是 1460 个字节（TCP 和 IP 的头各占用了 20 字节）。并且由于 TCP 是有序号和确认号的，接收方会缓存未按序到达的数据，根据序号重新排序报文段后再交给应用层。流量控制一般指的就是在接收方接受报文段的时候，应用层的上层程序可能在忙于做一些其他的事情，没有时间处理缓存中的数据，如果发送方在发送的时候不控制它的速度很有可能导致接受缓存溢出，导致数据丢失。相对的还有一种情况是由于两台主机之间的网络比较拥塞，如果发送方还是以一个比较快的速度发送的话就可能导致大量的丢包，这个时候也需要发送方降低发送的速度。虽然看起来上面的两种情况都是由于可能导致数据丢失而让发送主机降低发送速度，但是一定要把这两种情况分开，因为前者是属于 流量控制而后者是拥塞控制，那将是我们后面需要讨论的事情。不要把这两个概念混了。其实说到流量控制我们就不得不提一下滑动窗口协议，这个是流量控制的基础。由于 TCP 连接是一个全双工的也就是在发送的时候也是可以接受的，所以在发送端和接收端同时维持了发送窗口和接收窗口。这里为了方便讨论我们就按照单方向来讨论。接收方维持一个接受窗口，发送方一个发送窗口。发送的时候要知道接受窗口还有多少空间，也就是发送的数据量不能超过接受窗口的大小，否则就溢出了。而当我们收到一个接收方的 ACK 的时候我们就可以移动接受窗口把那些已经确认的数据滑动到窗口之外，发送窗口同理把确认的移出去。这样一直维持两个窗口大小，当接收方不能在接受数据的时候就把自己的窗口大小调整为 0 发送窗口就不会发送数据了。但是有一个问题，这个时候当接收窗口再调大的时候他不会主动通知发送方，这里采用的是发送方主动询问。还是画个图看的比较直观：拥塞控制一般都是由于网络中的主机发送的数据太多导致的拥塞，一般拥塞的都是一些负载比较高的路由，这时候为了获得更好的数据传输稳定性，我们必须采用拥塞控制，当然也为了减轻路由的负载防止崩溃。这里主要介绍两个拥塞控制的方法，一个是慢开始，另外一个称为快恢复。那么问题来了，为什么需要序号呢？为什么又是三次握手而不是两次？以及什么是 SYN 洪泛攻击？这里需要说明一下的是最后的那个长长的 TIME_WAIT 状态一般是为了客户端能够发出 ACK 一般他的值是 1分钟 或者2分钟好了，今天真的写了不少，主要就是把 TCP 的可靠传输以及连接管理讲清楚了，以及里面的一下细节问题，真的很花时间。然后其他没有涉及到的就是关于 TCP 的头并没有详细的去分析，这个东西其实也不是很难，但是现在篇幅真的已经很大就先这样，头里面的都是固定的不需要太多的理解。