关于tcp协议(关于tcp协议的端口,下列描述错误的是)

主要特点：面向连接、面向字节流、全双工通信、通信可靠。优缺点：应用场景：要求通信数据可靠时，即 数据要准确无误地传递给对方。如：传输文件：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

一个数据包的生命过程：数据包如何送达主机、主机如何将数据包转交给应用、数据是如何被完整地送达应用程序 互联网，实际上是一套理念和协议组成的体系架构 。其中，协议是一套众所周知的规则和标准，如果各方都同意使用，那么它们之间的通信将变得毫无障碍。数据通信是通过数据包来传输的。如果发送的数据很大，那么该数据就会被拆分为很多小数据包来传输。之后再由接收方按照数据包中的一定规则将小的数据包整合成全部数据。IP 是非常底层的协议，只负责把数据包传送到对方电脑，不负责该数据包将由哪个程序去使用。数据包要在互联网上进行传输，就要符合网际协议（Internet Protocol，简称 IP）标准。计算机的地址就称为 IP 地址，访问任何网站实际上只是你的计算机向另外一台计算机请求信息。简单理解数据传输过程就是：装包和拆包。 如果要想把一个数据包从主机 A 发送给主机 B，那么在传输之前，数据包上会被附加上主机 B 的 IP 地址信息，这样在传输过程中才能正确寻址。额外地，数据包上还会附加上主机 A 本身的 IP 地址，有了这些信息主机 B 才可以回复信息给主机 A。这些附加的信息会被装进一个叫 IP 头的数据结构里。IP 头是 IP 数据包开头的信息，包含 IP 版本、源 IP 地址、目标 IP 地址、生存时间等信息。过程：1、上层将含有“数据”的数据包交给网络层；2、网络层再将 IP 头附加到数据包上，组成新的 IP 数据包，并交给底层；3、底层通过物理网络将数据包传输给主机 B；4、数据包被传输到主机 B 的网络层，在这里主机 B 拆开数据包的 IP 头信息，并将拆开来的数据部分交给上层；5、最终，含有“数据”信息的数据包就到达了主机 B 的上层了。基于 IP 之上开发能和应用打交道的协议，最常见的是“用户数据包协议（User Datagram Protocol）”，简称 UDP。负责将传输的数据包交给某一应用程序。UDP 中一个最重要的信息是端口号，端口号其实就是一个数字，每个想访问网络的程序都需要绑定一个端口号。通过端口号 UDP 就能把指定的数据包发送给指定的程序了， 所以 IP 通过 IP 地址信息把数据包发送给指定的电脑，而 UDP 通过端口号把数据包分发给正确的程序。 和 IP 头一样，端口号会被装进 UDP 头里面，UDP 头再和原始数据包合并组成新的 UDP 数据包。UDP 头中除了目的端口，还有源端口号等信息。为了支持 UDP 协议，我把前面的三层结构扩充为四层结构，在网络层和上层之间增加了传输层过程：1、 上层将数据包交给传输层；传输层会在数据包前面附加上 UDP 头，组成新的 UDP 数据包，再将新的 UDP 数据包交给网络层；2、网络层再将 IP 头附加到数据包上，组成新的 IP 数据包，并交给底层；3、数据包被传输到主机 B 的网络层，在这里主机 B 拆开 IP 头信息，并将拆开来的数据部分交给传输层；4、在传输层，数据包中的 UDP 头会被拆开，并根据 UDP 中所提供的端口号，把数据部分交给上层的应用程序；5、最终，含有信息的数据包就旅行到了主机 B 上层应用程序这里。在使用 UDP 发送数据时，有各种因素会导致数据包出错，虽然 UDP 可以校验数据是否正确，但是对于错误的数据包， UDP 并不提供重发机制，只是丢弃当前的包 ，而且 UDP 在发送之后也无法知道是否能达到目的地。虽说UDP 不能保证数据可靠性，但是传输速度却非常快 ，所以 UDP 会应用在一些关注速度、但不那么严格要求数据完整性的领域，如在线视频、互动游戏等上文说到的使用UDP 来传输会存在两个问题 ：1、数据包在传输过程中容易丢失；2、大文件会被拆分成很多小的数据包来传输，这些小的数据包会经过不同的路由，并在不同的时间到达接收端，而 UDP 协议并不知道如何组装这些数据包，从而把这些数据包还原成完整的文件。所以TCP协议很好地解决的这个问题。TCP（Transmission Control Protocol，传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。1、对于数据包丢失的情况，TCP 提供重传机制；2、TCP 引入了数据包排序机制，用来保证把乱序的数据包组合成一个完整的文件。和 UDP 头一样，TCP 头除了包含了目标端口和本机端口号外，还提供了 用于排序的序列号 ，以便接收端通过序号来重排数据包一个完整的 TCP 连接的生命周期包括了“建立连接”“传输数据”和“断开连接”三个阶段。首先，建立连接阶段。这个阶段是通过“三次握手”来建立客户端和服务器之间的连接。TCP 提供面向连接的通信传输。面向连接是指在数据通信开始之前先做好两端之间的准备工作。所谓 三次握手 ，是指在建立一个 TCP 连接时，客户端和服务器总共要发送三个数据包以确认连接的建立。其次，传输数据阶段。在该阶段，接收端需要对每个数据包进行确认操作，也就是接收端在接收到数据包之后，需要发送确认数据包给发送端。所以当发送端发送了一个数据包之后，在规定时间内没有接收到接收端反馈的确认消息，则判断为数据包丢失，并触发发送端的重发机制。同样，一个大的文件在传输过程中会被拆分成很多小的数据包，这些数据包到达接收端后，接收端会按照 TCP 头中的序号为其排序，从而保证组成完整的数据。最后，断开连接阶段。数据传输完毕之后，就要终止连接了，涉及到最后一个阶段“ 四次挥手 ”来保证双方都能断开连接。三次握手和四次挥手限于篇幅可看另一篇文章： TCP协议中 的三次握手和四次挥手1、IP 负责把数据包送达目的主机。2、UDP 负责把数据包送达具体应用（可能会丢包)。3、而 TCP保证了数据完整地传输 ，它的连接可分为三个阶段：建立连接、传输数据和断开连接。 完整的数据流程

Transmission Control Protocol，传输控制协议，是一种面向连接的、可靠的、基于字节流的传输层通信协议TCP协议的目的是：在不可靠传输的IP层之上建立一套可靠传输的机制。TCP的可靠只是对于它自身来说的, 甚至是对于socket接口层, 两个系统就不是可靠的了, 因为发送出去的数据, 没有确保对方真正的读到（所以要在业务层做重传和确认机制）。可靠传输的第一要素是确认, 第二要素是重传, 第三要素是顺序。 任何一个可靠传输的系统, 都必须包含这三个要素。数据校验也是必要的。传输是一个广义的概念, 不局限于狭义的网络传输, 应该理解为通信和交互. 任何涉及到通信和交互的东西, 都可以借鉴TCP的思想。无论是在UDP上实现可靠传输或者创建自己的通信系统，无论这个系统是以API方式还是服务方式，只要是一个通信系统，就要考虑这三个要素。SeqNum的增加是和传输的字节数相关的。上图中，三次握手后，来了两个Len:1440的包，而第二个包的SeqNum就成了1441。然后第一个ACK回的是1441（下一个待接收的字节号），表示第一个1440收到了。网络上的传输是没有连接的，包括TCP也是一样的。而TCP所谓的“连接”，其实只不过是在通讯的双方维护一个“连接状态”，让它看上去好像有连接一样。所以，TCP的状态变换是非常重要的。查看各种状态的数量ss -ant | awk '{++s[$1]} END {for(k in s) print k,s[k]}'通过三次握手完成连接的建立三次握手的目的是交换通信双方的初始化序号，以保证应用层接收到的数据不会乱序，所以叫SYN(Synchronize Sequence Numbers)。ISN是不能hard code的，不然会出问题的。比如：如果连接建好后始终用1来做ISN，如果client发了30个segment过去，但是网络断了，于是client重连，又用了1做ISN，但是之前连接的那些包到了，于是就被当成了新连接的包，此时，client的Sequence Number可能是3，而Server端认为client端的这个号是30了。全乱了。RFC793中说，ISN会和一个假的时钟绑在一起，这个时钟会在每4微秒对ISN做加一操作，直到超过232，又从0开始。这样，一个ISN的周期大约是4.55个小时。因为，我们假设我们的TCP Segment在网络上的存活时间不会超过Maximum Segment Lifetime（MSL），所以，只要MSL的值小于4.55小时，那么，我们就不会重用到ISN。如果Server端接到了Clien发的SYN后回了SYN-ACK，之后Client掉线了，Server端没有收到Client返回的ACK，那么，这个连接就处于一个中间状态，即没成功，也没失败。于是，Server端如果在一定时间内没有收到的ACK会重发SYN-ACK。在Linux下，默认重试次数为5次，重试的间隔时间从1s开始每次都翻番，5次的重试时间间隔为1s, 2s, 4s, 8s, 16s，总共31s，第5次发出后还要等32s都知道第5次也超时了，所以，总共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 26 -1 = 63s，TCP才会断开这个连接。客户端给服务器发了一个SYN后，就下线了，于是服务器需要默认等63s才会断开连接，这样，攻击者就可以把服务器的SYN连接的队列耗尽，让正常的连接请求不能处理。于是，Linux下给了一个叫tcp_syncookies的参数来应对这个事：当SYN队列满了后，TCP会通过源地址端口、目标地址端口和时间戳打造出一个特别的Sequence Number发回去（又叫cookie），此时服务器并没有保留客户端的SYN包。如果是攻击者则不会有响应，如果是正常连接，则会把这个SYN Cookie发回来，然后服务端可以通过cookie建连接（即使你不在SYN队列中）。千万别用tcp_syncookies来处理正常的大负载的连接的情况。因为sync cookies是妥协版的TCP协议，并不严谨。应该调整三个TCP参数：tcp_synack_retries减少重试次数，tcp_max_syn_backlog增大SYN连接数，tcp_abort_on_overflow处理不过来干脆就直接拒绝连接因为TCP是全双工的，因此断开连接需要4次挥手，发送方和接收方都需要发送Fin和Ack。如果两边同时断连接，那就会就进入到CLOSING状态，然后到达TIME_WAIT状态。指的是报文段的最大生存时间，如果报文段在网络中活动了MSL时间，还没有被接收，那么会被丢弃。关于MSL的大小，RFC 793协议中给出的建议是两分钟，不过实际上不同的操作系统可能有不同的设置，以Linux为例，通常是半分钟，两倍的MSL就是一分钟，也就是60秒主动关闭的一方会进入TIME_WAIT状态，并且在此状态停留两倍的MSL时长。由于TIME_WAIT的存在，大量短连接会占有大量的端口，造成无法新建连接。主动关闭的一方发出 FIN包，被动关闭的一方响应ACK包，此时，被动关闭的一方就进入了CLOSE_WAIT状态。如果一切正常，稍后被动关闭的一方也会发出FIN包，然后迁移到LAST_ACK状态。CLOSE_WAIT状态在服务器停留时间很短，如果你发现大量的 CLOSE_WAIT状态，那么就意味着被动关闭的一方没有及时发出FIN包。TCP要保证所有的数据包都可以到达，所以，必需要有重传机制。接收端给发送端的Ack确认只会确认最后一个连续的包，比如，发送端发了1,2,3,4,5一共五份数据，接收端收到了1，2，于是回ack 3，然后收到了4（注意此时3没收到），此时的TCP会怎么办？我们要知道，因为正如前面所说的，SeqNum和Ack是以字节数为单位，所以ack的时候，不能跳着确认，只能确认最大的连续收到的包，不然，发送端就以为之前的都收到了但总体来说都不好。因为都在等timeout，timeout可能会很长不以时间驱动，而以数据驱动重传如果包没有连续到达，就ack最后那个可能被丢了的包，如果发送方连续收到3次相同的ack，就重传Selective Acknowledgment, 需要在TCP头里加一个SACK的东西，ACK还是Fast Retransmit的ACK，SACK则是汇报收到的数据碎版，在发送端就可以根据回传的SACK来知道哪些数据到了，哪些没有收到重复收到数据的问题，使用了SACK来告诉发送方有哪些数据被重复接收了经典算法：Karn/Partridge算法，Jacobson/Karels算法TCP必需要知道网络实际的数据处理带宽或是数据处理速度，这样才不会引起网络拥塞，导致丢包Advertised-Window：接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来接收端LastByteRead指向了TCP缓冲区中读到的位置，NextByteExpected指向的地方是收到的连续包的最后一个位置，LastByteRcved指向的是收到的包的最后一个位置，我们可以看到中间有些数据还没有到达，所以有数据空白区。发送端的LastByteAcked指向了被接收端Ack过的位置（表示成功发送确认），LastByteSent表示发出去了，但还没有收到成功确认的Ack，LastByteWritten指向的是上层应用正在写的地方。接收端在给发送端回ACK中会汇报自己的AdvertisedWindow = MaxRcvBuffer – LastByteRcvd – 1;收到36的ack，并发出了46-51的字节如果Window变成0了，发送端就不发数据了如果发送端不发数据了，接收方一会儿Window size 可用了，怎么通知发送端呢：TCP使用了Zero Window Probe技术，缩写为ZWP，也就是说，发送端在窗口变成0后，会发ZWP的包给接收方，让接收方来ack他的Window尺寸，一般这个值会设置成3次，每次大约30-60秒。如果3次过后还是0的话，有的TCP实现就会发RST把链接断了。如果你的网络包可以塞满MTU，那么你可以用满整个带宽，如果不能，那么你就会浪费带宽。避免对小的window size做出响应，直到有足够大的window size再响应。如果这个问题是由Receiver端引起的，那么就会使用David D Clark’s 方案。在receiver端，如果收到的数据导致window size小于某个值，可以直接ack(0)回sender，这样就把window给关闭了，也阻止了sender再发数据过来，等到receiver端处理了一些数据后windows size大于等于了MSS，或者receiver buffer有一半为空，就可以把window打开让send 发送数据过来。如果这个问题是由Sender端引起的，那么就会使用著名的 Nagle’s algorithm。这个算法的思路也是延时处理，他有两个主要的条件：1）要等到 Window Size >= MSS 或是 Data Size >= MSS，2）等待时间或是超时200ms，这两个条件有一个满足，他才会发数据，否则就是在攒数据。TCP_CORK是禁止小包发送，而Nagle算法没有禁止小包发送，只是禁止了大量的小包发送TCP不是一个自私的协议，当拥塞发生的时候，要做自我牺牲拥塞控制的论文请参看 《Congestion Avoidance and Control》主要算法有：慢启动，拥塞避免，拥塞发生，快速恢复，TCP New Reno，FACK算法，TCP Vegas拥塞控制算法TCP网络协议及其思想的应用TCP 的那些事儿（上）TCP 的那些事儿（下）tcp为什么是三次握手，为什么不是两次或四次？记一次TIME_WAIT网络故障再叙TIME_WAITtcp_tw_recycle和tcp_timestamps导致connect失败问题tcp短连接TIME_WAIT问题解决方法大全（1）- 高屋建瓴tcp短连接TIME_WAIT问题解决方法大全（2）- SO_LINGERtcp短连接TIME_WAIT问题解决方法大全（3）- tcp_tw_recycletcp短连接TIME_WAIT问题解决方法大全（4）- tcp_tw_reusetcp短连接TIME_WAIT问题解决方法大全（5）- tcp_max_tw_bucketsTCP的TIME_WAIT快速回收与重用浅谈CLOSE_WAIT又见CLOSE_WAITPHP升级导致系统负载过高问题分析Coping with the TCP TIME-WAIT state on busy Linux servers

1、完成对数据报的确认、流量控制和网络拥塞。2、自动检测数据报，并提供错误重发的功能。3、将多条路径传送的数据报按照原来的顺序进行排列。4、控制超时重发，自动调整超时值。tcp协议简介：TCP（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793定义。在简化的计算机网络OSI模型中，它完成第四层传输层所指定的功能，用户数据报协议（UDP）是同一层内 [1] 另一个重要的传输协议。在因特网协议族（Internet protocol suite）中，TCP层是位于IP层之上，应用层之下的中间层。不同主机的应用层之间经常需要可靠的、像管道一样的连接，但是IP层不提供这样的流机制，而是提供不可靠的包交换。
功能是完成对数据报的确认、流量控制和网络拥塞。1、在数据正确性与合法性上，TCP用一个校验和函数来检验数据是否有错误，在发送和接收时都要计算校验和；同时可以使用md5认证对数据进行加密。2、在保证可靠性上，采用超时重传和捎带确认机制。3、在流量控制上，采用滑动窗口协议，协议中规定，对于窗口内未经确认的分组需要重传。TCP是一种面向广域网的通信协议，目的是在跨越多个网络通信时，为两个通信端点之间提供一条具有下列特点的通信方式：1、基于流的方式。2、面向连接。3、可靠通信方式。4、在网络状况不佳的时候尽量降低系统由于重传带来的带宽开销。5、通信连接维护是面向通信的两个端点的，而不考虑中间网段和节点。
tcp协议的主要功能：1、完成对数据报的确认、流量控制和网络拥塞；2、自动检测数据报，并提供错误重发的功能；3、将多条路径传送的数据报按照原来的顺序进行排列；4、控制超时重发，自动调整超时值。tcp协议的工作方式1、建立连接TCP是因特网中的传输层协议，使用三次握手协议建立连接。当主动方发出SYN连接请求后，等待对方回答SYN+ACK，并最终对对方的 SYN 执行 ACK 确认。这种建立连接的方法可以防止产生错误的连接，TCP使用的流量控制协议是可变大小的滑动窗口协议。2、连接终止建立一个连接需要三次握手，而终止一个连接要经过四次握手，这是由TCP的半关闭（half-close）造成的。

TCP/IP协议是现在互联网的基础。TCP/IP协议主要有如下的特点。 1、TCP/IP协议是一个开放的协议标准，所有人都可以免费试用，并且是独立于硬件和操作系统的。2、TCP/IP协议是不区分网络硬件的，它在局域网，广域网和互联网中都被广泛使用。3、TCP/IP协议使用统一的网络地址分配的方案。网络中的每台电脑都具有唯一的IP地址。 4、TCP/IP协议是一个标准的高层协议，拥有极高的可靠性，可以为用户提供可靠的服务。
TCP/IP协议是现在互联网的基础。TCP/IP协议主要有如下的特点。 1、TCP/IP协议是一个开放的协议标准，所有人都可以免费试用，并且是独立于硬件和操作系统的。2、TCP/IP协议是不区分网络硬件的，它在局域网，广域网和互联网中都被广泛使用。3、TCP/IP协议使用统一的网络地址分配的方案。网络中的每台电脑都具有唯一的IP地址。 4、TCP/IP协议是一个标准的高层协议，拥有极高的可靠性，可以为用户提供可靠的服务。
TCP/IP协议bai是du现在互联网的基础。TCP/IP协议主要有如下的特点zhi。 1、TCP/IP协议是一个开放dao的协议标准，所有人zhuan都可以免费shu试用，并且是独立于硬件和操作系统的。2、TCP/IP协议是不区分网络硬件的，它在局域网，广域网和互联网中都被广泛使用。3、TCP/IP协议使用统一的网络地址分配的方案。网络中的每台电脑都具有唯一的IP地址。 4、TCP/IP协议是一个标准的高层协议，拥有极高的可靠性，可以为用户提供可靠的服务。