tcp连接复用(tcp复用分用)

TCP是传输控制协议。TCP（Transmission Control Protocol）是网络通信模型OSI7层网络模型中，第四层传输层协议，主要作用是数据传输，TCP 主要确保不同节点之间的端到端数据传输。在因特网协议族中，TCP 层是位于 IP 层之上，应用层之下的中间层，是一种面向连接的、可靠的、基于字节流的传输层通信协议。在传输过程中，为保证传输质量，TCP 层将大数据分成长度合适的较小的数据包，分别发送，并确保在目标节点重组后数据完整性保持不变。扩展资料：1、应用层与TCP之间：应用层向 TCP 层发送用于网间传输的数据流，这些数据流是 8 位字节，TCP收到后会把数据流分割成适当长度的报文段。2、TCP层和IP层：TCP 把适当长度的报文段传给 IP 层，为了保证不发生丢包，TCP会把每个包命名一个序号，接收端按照序号接收。3、接收端实体成功收到的包会再发回一个确认ACK；如果发送端实体在响应时间内没有收到该确认，就会进行重传。参考资料来源：百度百科---TCP
传输控制协议（TCP，Transmission Control Protocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793 定义。传输原理为当应用层向TCP层发送用于网间传输的、用8位字节表示的数据流，TCP则把数据流分割成适当长度的报文段，最大传输段大小（MSS）通常受该计算机连接的网络的数据链路层的最大传送单元（MTU）限制。之后TCP把数据包传给IP层，由它来通过网络将包传送给接收端实体的TCP层。TCP为了保证报文传输的可靠，就给每个包一个序号，同时序号也保证了传送到接收端实体的包的按需接收。然后接收端实体对已成功收到的字节发回一个相应的确认（ACK）；如果发送端实体在合理的往返时延（RTT）内未收到确认，那么对应的数据（假设丢失了）将会被重传。扩展资料：CP/IP传输协议作为在网络的使用中的最基本的通信协议，得到了广泛应用。TCP/IP传输协议对互联网中各部分进行通信的标准和方法进行了规定。并且，TCP/IP传输协议是保证网络数据信息及时、完整传输的两个重要的协议。TCP/IP协议在一定程度上参考了OSI的体系结构。OSI模型共有七层，从下到上分别是物理层、数据链路层、网络层、运输层、会话层、表示层和应用层。TCP/IP协议能够迅速发展起来并成为事实上的标准，是它恰好适应了世界范围内数据通信的需要。参考资料来源：百度百科-TCP参考资料来源：百度百科-TCP/IP协议
传输控制协议 TCP 是 TCP/IP 协议栈中的传输层协议，它通过序列确认以及包重发机制，提供可靠的数据流发送和到应用程序的虚拟连接服务。与 IP 协议相结合， TCP 组成了因特网协议的核心。　　由于大多数网络应用程序都在同一台机器上运行，计算机上必须能够确保目的地机器上的软件程序能从源地址机器处获得数据包，以及源计算机能收到正确的回复。这是通过使用 TCP 的“端口号”完成的。网络 IP 地址和端口号结合成为唯一的标识 , 我们称之为“套接字”或“端点”。 TCP 在端点间建立连接或虚拟电路进行可靠通信。　　TCP 服务提供了数据流传输、可靠性、有效流控制、全双工操作和多路复用技术等。　　关于流数据传输 ,TCP 交付一个由序列号定义的无结构的字节流。 这个服务对应用程序有利，因为在送出到 TCP 之前应用程序不需要将数据划分成块， TCP 可以将字节整合成字段，然后传给 IP 进行发送。　　TCP 通过面向连接的、端到端的可靠数据报发送来保证可靠性。 TCP 在字节上加上一个递进的确认序列号来告诉接收者发送者期望收到的下一个字节。如果在规定时间内，没有收到关于这个包的确认响应，重新发送此包。 TCP 的可靠机制允许设备处理丢失、延时、重复及读错的包。超时机制允许设备监测丢失包并请求重发。　　TCP 提供了有效流控制。当向发送者返回确认响应时，接收 TCP 进程就会说明它能接收并保证缓存不会发生溢出的最高序列号。　　全双工操作： TCP 进程能够同时发送和接收包。　　TCP 中的多路技术：大量同时发生的上层会话能在单个连接上时进行多路复用。 您觉得这个答案好不好？好(1)不好(0)jianzhu 2007-06-13 22:26 相关问题�6�1 TCP/IP是什么�6�1 TCP/IP�6�1 关于TCP/IP的问题�6�1 TCP是什么意思�6�1 什么是TCP？相关搜索 tcp是什么意思 tcp ip协议 什么是tcp ip协议 tcp optimizer tcp数据包是什么 tcp ip tcp ip协议下载 tcp数据包 其他答案 传输控制协议 TCP 是 TCP/IP 协议栈中的传输层协议，它通过序列确认以及包重发机制，提供可靠的数据流发送和到应用程序的虚拟连接服务。与 IP 协议相结合， TCP 组成了因特网协议的核心。 但是在Socket开发中TCP象征着有连接点对点,UDP相反 也可有广播的功能!
TCP，是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP通过下列方式来提供可靠性，第一应用数据被分割成TCP认为最适合发送的数据块；第二当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段；第三TCP将保持它首部和数据的检验和；第四既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序；第五既然IP数据报会发生重复，TCP的接收端必须丢弃重复的数据；第六TCP还能提供流量控制。

整理自 CSDN 公众号1. 客户端TCP 三次握手的开始是客户端发起 SYN，如果服务端没有及时回复，那么会重传，重传的间隔和次数是可控的，默认是五次，第一次间隔 1 秒，第二次 2 秒，第三次 4 秒，第四次 8 秒，第五次16 秒，最终超时时间是 63 秒，因此在优化时可以修改重传次数和间隔，以尽快把错误暴露给应用程序。2. 服务端的半连接队列优化服务端在第一次返回 SYN + ACK 时，就会把这次请求维护进一个半连接队列，这个队列用来维护尚未完成的握手信息（相对于全连接），如果这个队列溢出了，服务端就无法继续接受新的请求了，这也是 SYN Flood 攻击的点。通过一个命令 netstat -s 可以得到累计的、由于半连接队列已满引发的失败次数，隔几秒执行一次就可以知道这个次数是否有上升的趋势以及分析是否正常。这种 SYN Flood 攻击之所以成立，是因为维护这个半连接队列一定要分配一定的内存资源，那么应对的方式之一 syncookies 就是如何不分配资源的前提下，可以确认是一次有效的连接并 establish。syncookies 的工作原理是，服务器使用一种算法，计算出一个哈希值，它包含了客户端发来请求的部分信息，再将这个哈希值和 SYN+ACK 一起返回给客户端，客户端也经过一些运算，再返回给服务端，那么服务端根据这个返回值和之前的计算值比较，如果合法，就可以建立有效连接，从而不会占据半连接队列的内存。应对 SYN 攻击时，只需将 syncookies 的参数值调为 1（半连接队列溢出时启用），即可。相当的，可以增大半连接队列，但是要和 accept 的队列同时增大才有效，（否则会导致 accept 队列溢出同样丢失 TCP 连接）此时，对于客户端来说已经是 established 状态，但是还要再返回给服务端一个 ACK，服务端收到后，服务端才是 established 状态并开始传数据，如果网络不稳定，同样的，服务端会重发 SYN+ACK，当网络不稳定时，应该增加服务端重发 SYN+ACK 的次数。3. 服务端的 accept 队列优化当连接已经建立、应用程序尚未调用时，TCP 连接会被保存在一个 accept 队列中，如果进程未能及时调用，就会导致 accept 队列溢出，溢出部分连接将被默认丢弃。对此可以做的是，选择向客户端发送 RST 报文，告知关闭这个连接，丢弃握手过程。打开这一功能需要将 tcp_abort_on_overflow 参数设置为 1。如果想让客户端了解是由于 accept 队列溢出造成连接失败可以这样做。当 tcp_abort_on_overflow 参数设置为 0 时，则如果 accept 队列溢出，就会丢弃客户端传来的 ACK（用于最后一次握手）。应对高并发流量时，更好的选择是 tcp_abort_on_overflow 参数设置为 0，这样对于客户端它的状态仍然是 established，客户端会定时发送带有 ack 报文的发送数据请求，一旦服务端的 accept 队列有空位，那么连接仍有可能建立成功。所以只有很确定在一段时间内 accept 都是将溢出的状态，才推荐 tcp_abort_on_overflow 参数设置为 1。同样的，可以调整 accept 队列长度，也可以查看累计的由于溢出导致丢失的连接总数，来判断趋势。在 Linux 3.7 内核版本之后，提供了 TCP Fast Open 功能，这个功能如此生效：初次建立 TCP 连接时，客户端在第一个 SYN 包中传入一个请求 cookie，表明打开 fast open 功能，服务端对应生成一个 cookie 给客户端，除此之外，三次握手没有不同，但是，在 cookie 没有过期之前，下一次再连接的时候，客户端发送带有 cookie 的 SYN 包，服务端校验了 cookie 有效以后，就可以开始传输数据了，从而节约了一个往返的时间消耗。TCP Fast Open 功能需要服务端和客户端同时打开才能生效。（备注一个之前看到差点忘了的知识点。当主动方收到被动方的 FIN 报文后，内核会回复 ACK 报文给被动方，同时主动方的连接状态由 FIN_WAIT2 变为 TIME_WAIT，在 Linux 系统下大约等待 1 分钟后，TIME_WAIT 状态的连接才会彻底关闭。1. 主动方的优化关闭的方式有两种 RST 和 FIN，RST 是暴力关闭连接的方式，安全关闭连接则必须四次挥手。FIN 报文关闭则可以使用 close 和 shutdown 两种函数来实现。close 相对来说是“不优雅”的，调用 close 的一方的连接叫做「孤儿连接」，会同时关闭读和写，而 shutdown 可以控制是读还是写。关闭读的时候，会丢弃接收缓冲区里的所有数据，如果后续再接受到数据，也会悄悄丢弃，并发送 ACK，对方不会知道被丢弃了。关闭写的时候，会把发送缓冲区的数据全部发送并发送 FIN。（1）FIN_WAIT1 的优化主动方发送 FIN 以后，进入 FIN_WAIT1 状态，如果迟迟没收到 ACK，会定时重发 FIN，重发次数由 tcp_orphan_retries 参数控制，默认为 8 次，如果处于 FIN_WAIT1 状态的连接过多，应该考虑降低次数，重发次数超过参数时，连接会被直接关闭。如果遇到恶意攻击，可能无法发送出 FIN，因为 TCP 按顺序发送所有包， FIN 也不能绕过，另外如果对方的接收窗口已经满了，发送方也无法再发送数据。此时应该做的是调整 tcp_max_orphans 参数，它定义了「孤儿连接」的最大数量，当系统中的孤儿连接超过参数值，新增的孤儿连接不会再处于 FIN_WAIT1 状态，而是会被 RST 报文直接关闭。（只会影响 CLOSE 函数关闭的连接，不会影响 shutdown 关闭的，不会影响还有读或写的可能）（2）FIN_WAIT2 的优化主动方收到 ACK 后，会处于 FIN_WAIT2，因为被动方还可能有数据发送，如果是 shutdown 关闭，那它也可能还会发送数据，但是对于 close 关闭的连接，无法再发送和接收数据，保持在 FIN_WAIT2 的状态已经没有太大意义，tcp_fin_timeout 控制了这个状态下连接的持续时长，默认值是 60 秒。这个时间和 TIME_WAIT 状态时长是一致的。（3）TIME_WAIT 的优化TIME_WAIT 和 FIN_WAIT2 的时间是一致的，都是 2MSL，1MSL 表示一个报文在网络中存活的最长时间（报文每经过一次路由器的转发，IP 头部的 TTL 字段就会减 1，减到 0 时报文就被丢弃，这就限制了报文的最长存活时间），那么为什么是等待 2MSL 呢，其实就是允许报文至少丢失一次、再发送一次，这样第一个丢失了，等待的时间里第二个 ACK 还会到达，为什么不是 4MSL 以上呢，这是一个概率的问题，如果一个网络丢包率达到 1%，那么连续两次丢包的概率是万分之一，不必为了这种概率增加等待的时长。TIME_WAIT 有存在的意义，但是太多保持在这种状态的连接会占用双方资源，占据客户端的端口资源和服务端的系统资源。Linux 提供了 tcp_max_tw_buckets 参数，当 TIME_WAIT 的连接数量超过该参数时，新关闭的连接就不再经历 TIME_WAIT 而直接关闭。这个参数的设定应该取一个平衡点，即既不会太少导致高并发时产生连接间数据错乱的问题，也不会太多而导致耗尽端口和线程资源。对于用户端来讲，还可以启用 tcp_tw_reuse 参数来复用处于 TIME_WAIT 状态的连接（来节约接口资源。）这个参数有几个前提，一个是只有客户端可以打开，一个是 TIME_WAIT 状态也要保持 1 秒，另一个是要同步打开时间戳功能，报文带上时间戳就可以避免没有了 2MSL 时长以后的混乱情况，时间戳过期的报文就会被丢掉。另外对于 TIME_WAIT，还可以调整 socket 选项，来达到调用 close 关闭连接时跳过四次挥手直接关闭的效果，但不推荐。2. 被动方的优化首先，被动方收到 FIN 时，会自动回复 ACK，接着等待应用程序调用 close/shutdown 来结束连接，再发送 FIN。如果系统中同时查看到多个连接处于 CLOSE_WAIT 状态，则需要排查是否是应用程序出了故障。然后，当被动方也发送了 FIN 以后，还需要等待主动方回复一个 ACK，如果迟迟没收到，也会重发 FIN，重发次数也是 tcp_orphan_retries 参数控制，这点和主动方的优化一致，可以调整次数。（需确认被动方是否有 tcp_max_orphans 参数）3. 如果双方同时关闭？1.ACK 延迟目前在 TCP 中每传输一个报文都要求接收方进行确认，大量短而频繁的确认报文给网络带来了很多开销。因此采取了延迟 ACK 策略来减少 ACK 的数量，就是接收方收到一个报文以后，不会立即发送 ACK，而是等待 1~200ms，这期间若有回送数据报文就捎带确认，但收到两个连续数据报文或者等待超时则发送一个独立确认。有效减少了 ACK 的数量，改善了 TCP 的整体性能。2. 滑动窗口接收方的接收缓冲区不是不变的，接收到新的会变小，应用程序取出后又会变大，因此接收方会把自己当前的接收窗口大小放在 TCP 头告知发送方，如果不考虑拥塞控制，发送方的窗口大小「约等于」接收方的窗口大小。对于这一点，可以把 tcp_window_scaling 配置设为 1（默认打开）来扩大 TCP 通告窗口至 1G 大小。要使用这一选项，需要主动方在 SYN 中先告知，被动方在 SYN 中再反馈。但是缓冲区并非越大越好，还要考虑网络吞吐的能力。如果缓冲区与网络传输能力匹配，那么缓冲区的利用率就达到了最大化。3. 调整缓冲区大小这里需要说一个概念，就是带宽时延积，它决定网络中飞行报文的大小，它的计算方式：（1）发送缓冲区的调整发送缓冲区是自行调节的，当发送方发送的数据被确认后，并且没有新的数据要发送，就会把发送缓冲区的内存释放掉。接收缓冲区要复杂一些：上面三个数字单位都是字节，它们分别表示：（2）接收缓冲区的调整接收缓冲区可以根据系统空闲内存的大小来调节接收窗口：（3）内存的判断那么如何判断内存紧张或充分呢？上面三个数字单位不是字节，而是「页面大小」，1 页表示 4KB，它们分别表示：在实际的场景中，TCP 缓冲区最小值保持默认 4K 即可，来提高并发处理能力；最大值则尽可能靠近带宽时延积，来最大化网络效率。总结以上：为了提高并发能力、提高网络效率，我们要充分利用网络能力和自己的内存。网络这方面就是将缓冲区大小的极值尽可能靠近带宽时延积，而同时对缓冲区的自动调节需要结合内存来判断，这个 TCP 内存的判断是通过系统内存计算出来的几个值来划分的，在不同区间会对分配给缓冲区的内存大小进行调整。以上就是 TCP 在不同阶段的优化策略和思路，有关拥塞控制和流量控制之后再补一篇笔记。

TCP是一种传输控制协议，是面向连接的、可靠的、基于字节流之间的传输层通信协议，由IETF的RFC 793定义。在简化的计算机网络OSI模型中，TCP完成第四层传输层所指定的功能，用户数据报协议（UDP）是同一层内另一个重要的传输协议。在因特网协议族（Internet protocol suite）里面，TCP层是在IP层上面，应用层下面的一个中间层。不同主机的应用层之间经常会要用到可靠的、像管道一样的连接，但是IP层不会提供这样的流机制，而是提供不可靠的包交换。扩展资料：当应用层向TCP层发送用于网间传输的、用8位字节表示的数据流，TCP则把数据流分割成适当长度的报文段，最大传输段大小（MSS）通常受该计算机连接的网络的数据链路层的最大传送单元（MTU）限制。之后TCP把数据包传给IP层，由它来通过网络将包传送给接收端实体的TCP层。TCP为了保证报文传输的可靠，就给每个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认(ACK)；如果发送端实体在合理的往返时延(RTT)内未收到确认，那么对应的数据（假设丢失了）将会被重传。参考资料：百度百科-TCP （传输控制协议）
TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议。拓展资料：在简化的计算机网络OSI模型中，它完成第四层传输层所指定的功能，用户数据报协议是同一层内另一个重要的传输协议。在因特网协议族中，TCP层是位于IP层之上，应用层之下的中间层。不同主机的应用层之间经常需要可靠的、像管道一样的连接，但是IP层不提供这样的流机制，而是提供不可靠的包交换。功能：当应用层向TCP层发送用于网间传输的、用8位字节表示的数据流，TCP则把数据流分割成适当长度的报文段，最大传输段大小通常受该计算机连接的网络的数据链路层的最大传送单元限制。之后TCP把数据包传给IP层，由它来通过网络将包传送给接收端实体的TCP层。
TCP：传输控制协议 （TCP：Transmission Control Protocol）传输控制协议 TCP 是 TCP/IP 协议栈中的传输层协议，它通过序列确认以及包重发机制，提供可靠的数据流发送和到应用程序的虚拟连接服务。与 IP 协议相结合， TCP 组成了因特网协议的核心。由于大多数网络应用程序都在同一台机器上运行，计算机上必须能够确保目的地机器上的软件程序能从源地址机器处获得数据包，以及源计算机能收到正确的回复。这是通过使用 TCP 的“端口号”完成的。网络 IP 地址和端口号结合成为唯一的标识 , 我们称之为“套接字”或“端点”。 TCP 在端点间建立连接或虚拟电路进行可靠通信。TCP 服务提供了数据流传输、可靠性、有效流控制、全双工操作和多路复用技术等。关于流数据传输 ,TCP 交付一个由序列号定义的无结构的字节流。 这个服务对应用程序有利，因为在送出到 TCP 之前应用程序不需要将数据划分成块， TCP 可以将字节整合成字段，然后传给 IP 进行发送。TCP 通过面向连接的、端到端的可靠数据报发送来保证可靠性。 TCP 在字节上加上一个递进的确认序列号来告诉接收者发送者期望收到的下一个字节。如果在规定时间内，没有收到关于这个包的确认响应，重新发送此包。 TCP 的可靠机制允许设备处理丢失、延时、重复及读错的包。超时机制允许设备监测丢失包并请求重发。TCP 提供了有效流控制。当向发送者返回确认响应时，接收 TCP 进程就会说明它能接收并保证缓存不会发生溢出的最高序列号。全双工操作： TCP 进程能够同时发送和接收包。 TCP 中的多路技术：大量同时发生的上层会话能在单个连接上时进行多路复用。
TCP(Transmission Control Protocol 传输控制协议)是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793定义。在简化的计算机网络OSI模型中，它完成第四层传输层所指定的功能，用户数据报协议(UDP)是同一层内另一个重要的传输协议。在因特网协议族(Internet protocol suite)中，TCP层是位于IP层之上，应用层之下的中间层。不同主机的应用层之间经常需要可靠的、像管道一样的连接，但是IP层不提供这样的流机制，而是提供不可靠的包交换。
两个核心协议：TCP（传输控制协议）和IP（网际协议）TCP使用三次握手协议建立连接。三次握手完成，TCP客户端和服务器端成功地建立连接，可以开始传输数据了。（HTTP是一个客户端和服务器端请求和应答的标准（TCP），它是建立在TCP协议之上的一种应用。)IP实现两个基本功能：寻址和分段。IP协议的作用主要有两个，一个是为每一台计算机分配IP地址，另一个是确定哪些地址在同一个子网络。IP协议是找到对方的详细地址,TCP协议是把安全的把数据传输给对方。

通常会采用修改注册表的方式改进Windows的系统参数。下面将为大家介绍Windows系统下的TCP参数优化方式，适用于Windows 2003、Windows XP、Windows 7以及Server版。对于具体的系统环境与性能需求，优化方式会有所差异，效果也不尽相同，仅是个人的建议。所有的优化操作都通过修改注册表实现，需要使用regedit命令进入注册表并创建或修改参数，修改完成后需要重启系统，以使之生效。以下使用的参数值均为10进制。1. TCPWindowSizeTCPWindowSize的值表示TCP的窗口大小。TCP Receive Window（TCP数据接收缓冲）定义了发送端在没有获得接收端的确认信息的状态下可以发送的最大字节数。此数值越大，返回的确认信息就越少，相应的在发送端和接收端之间的通信就越好。此数值较小时可以降低发送端在等待接收端返回确认信息时发生超时的可能性，但这将增加网络流量，降低有效吞吐率。TCP在发送端和接收端之间动态调整一个最大段长度MSS（Maximum Segment Size）的整数倍。MSS在连接开始建立时确定，由于TCP Receive Window被调整为MSS的整数倍，在数据传输中完全长度的TCP数据段的比例增加，故而提高了网络吞吐率。缺省情况下，TCP将试图根据MSS来优化窗口大小，起始值为16KB，最大值为64KB。TCPWindowSize的最大值通常为65535字节（64KB），以太网最大段长度为1460字节，低于64KB的1460的最大整数倍为62420字节，因而可以在注册表中将TCPWindowSize设置为62420，作为高带宽网络中适用的性能优化值。具体操作如下：浏览至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注册表子键，在Parameters子键下创建或修改名为TCPWindowSize的REG_DWORD值，该值的范围是从0到65535，将该值设置为62420。2. TCP1323Opts为了更高效地利用高带宽网络，可以使用比上述TCP窗口大得多的TCP窗口大小，此特性是Windows 2000和Windows Server 2003中的新特性，称为TCP Window Scaling，它将以前的65535字节（64KB）的限制提高到了1073741824字节（1GB）。在带宽与延迟的乘积值很高的连接上（例如卫星连接），可能需要将窗口的大小增加到64KB以上。使用TCP Window Scaling，系统可以允许确认信息间更大数据量的传输，增加了网络吞吐量及性能。发送端和接收端往返通信所需的时间被称为回环时间（RTT）。TCP Window Scaling仅在TCP连接的双方都开启时才真正有效。TCP有一个时间戳选项，通过更加频繁地计算来提高RTT值的估测值，此选项特别有助于估测更长距离的广域网上连接的RTT值，并更加精确地调整TCP重发超时时间。时间戳在TCP报头提供了两个区域，一个记录开始重发的时间，另一个记录接收到的时间。时间戳对于TCP Window Scaling，即确认信息收到前的大数据包传送特别有用，激活时间戳仅仅在每个数据包的头部增加12字节，对网络流量的影响微乎其微。数据完整性与数据吞吐率最大化哪个更为重要是个需要评估的问题。在某些环境中，例如视频流传输，需要更大的TCP窗口，这是最重要的，而数据完整性排在第二位。在这种环境中，TCP Window Scaling可以不打开时间戳。当发送端和接收端均激活TCP Window Scaling和时间戳时，此特性才有效。不过，若在发包时加入了时间戳，经过NAT之后，如果前面相同的端口被使用过，且时间戳大于这个连接发出的SYN中的时间戳，就会导致服务器忽略该SYN，表现为用户无法正常完成TCP的3次握手。初始时生成小的TCP窗口，之后窗口大小将按照内部算法增大。具体操作如下：浏览至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注册表子键，在Parameters子键下创建或修改名为TCP1323Opts的REG_DWORD值，该值的具体含义为：0（缺省值）表示禁用TCP Window Scaling和时间戳；1表示只启用TCP Window Scaling；2表示只启用时间戳；3表示同时启用TCP Window Scaling和时间戳。TCP1323Opts设置为激活TCP Window Scaling后，可以将上文中的注册表项TCPWindowSize的值增大，最大能达到1GB，为了达到最佳性能，这里的值最好设置成MSS的倍数，推荐值为256960字节。3. TCP 控制块表对于每个TCP连接，控制变量保存在一个称为TCP控制块（TCB）的内存块中。TCB表的大小由注册表项MaxHashTableSize控制。在活动连接很多的系统中，设定一个较大的表可以降低系统定位TCB表的时间。在TCB表上分区可以降低对表的访问的争夺。增加分区的数量，TCP的性能会得到优化，特别是在多处理器的系统上。注册表项NumTcbTablePartitions控制分区的数量，默认是处理器个数的平方。TCB通常预置在内存中，以防止TCP反复连接和断开时，TCB反复重新定位浪费时间，这种缓冲的方式促进了内存管理，但同时也限制了同一时刻允许的TCP连接数量。注册表项MaxFreeTcbs决定了处于空闲等待状态的TCB重新可用之前的连接数量，在NT架构中常设置成高于默认值，以确保有足够的预置的TCB。从Windows 2000开始添加了一个新特性，降低超出预置TCB运行的可能性。如果处于等待状态的连接多于MaxFreeTWTcbs中的设置，所有等待时间超过60秒的连接将被强制关闭，以后再次启用。此特性合并到Windows 2000 Server和Windows Server 2003后，MaxFreeTcbs将不再用于优化性能。具体操作：浏览至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注册表子键，在Parameters子键下创建或修改名为MaxHashTableSize的REG_DWORD值，该值的范围是从1到65536，并且必须为2的N次方，缺省值为512，建议设为8192。然后在Parameters子键下创建或修改名为NumTcbTablePartitions的REG_DWORD值，该值的范围是从1到65536，并且必须为2的N次方，缺省值为处理器个数的平方，建议设为处理器核心数的4倍。4. TcpTimedWaitDelayTcpTimedWaitDelay的值表示系统释放已关闭的TCP连接并复用其资源之前，必须等待的时间。这段时间间隔就是以前的Blog中提到的TIME_WAIT状态（2MSL，数据包最长生命周期的两倍状态）。如果系统显示大量连接处于TIME_WAIT状态，则会导致并发量与吞吐量的严重下降，通过减小该项的值，系统可以更快地释放已关闭的连接，从而为新连接提供更多的资源，特别是对于高并发短连接的Server具有积极的意义。该项的缺省值是240，即等待4分钟后释放资源；系统支持的最小值为30，即等待时间为30秒。具体操作：浏览至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注册表子键，在Parameters子键下创建或修改名为TcpTimedWaitDelay的REG_DWORD值，该值的范围是从0到300，建议将该值设置为30。5. MaxUserPortMaxUserPort的值表示当应用程序向系统请求可用的端口时，TCP/IP可分配的最大端口号。如果系统显示建立连接时出现异常，那么有可能是由于匿名（临时）端口数不够导致的，特别是当系统打开大量端口来与Web service、数据库或其他远程资源建立连接时。该项的缺省值是十进制的5000，这也是系统允许的最小值。Windows默认为匿名（临时）端口保留的端口号范围是从1024到5000。为了获得更高的并发量，建议将该值至少设为32768以上，甚至设为理论最大值65534，特别是对于模拟高并发测试环境的Client具有积极的意义。具体操作：浏览至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注册表子键，在Parameters子键下创建或修改名为MaxUserPort的REG_DWORD值，该值的范围是从5000到65534，缺省值为5000，建议将该值设置为65534。6. 动态储备动态储备的值使系统能自动调整其配置，以接受大量突发的连接请求。如果同时接收到大量连接请求，超出了系统的处理能力，那么动态储备就会自动增大系统支持的暂挂连接的数量（即Client已请求而Server尚未处理的等待连接数，TCP连接的总数包括已连接数与等待连接数），从而可减少连接失败的数量。系统的处理能力和支持的暂挂连接的数量不足时，Client的连接请求将直接被拒绝。缺省情况下，Windows 不启用动态储备，可以通过以下操作进行开启和设置：浏览至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesAFDParameters注册表子键，在Parameters子键下创建或修改下列名称的REG_DWORD值。EnableDynamicBacklog，值为1，表示开启动态储备。MinimumDynamicBacklog，值为128，表示支持的最小暂挂连接的数量为128。MaximumDynamicBacklog，值为2048，表示支持的最大暂挂连接的数量为2048。对于高并发短连接的Server，建议最大值设为1024及以上。DynamicBacklogGrowthDelta，值为128，表示支持的暂挂连接的数量的增量为128，即数量不足时自增长128，直到达到设定的最大值，如2048。7. KeepAliveTimeKeepAliveTime的值控制系统尝试验证空闲连接是否仍然完好的频率。如果该连接在一段时间内没有活动，那么系统会发送保持连接的信号，如果网络正常并且接收方是活动的，它就会响应。如果需要对丢失接收方的情况敏感，也就是说需要更快地发现是否丢失了接收方，请考虑减小该值。而如果长期不活动的空闲连接的出现次数较多，但丢失接收方的情况出现较少，那么可能需要增大该值以减少开销。缺省情况下，如果空闲连接在7200000毫秒（2小时）内没有活动，系统就会发送保持连接的消息。 通常建议把该值设为1800000毫秒，从而丢失的连接会在30分钟内被检测到。具体操作：浏览至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注册表子键，在Parameters子键下创建或修改名为KeepAliveTime的REG_DWORD值，为该值设置适当的毫秒数。8. KeepAliveIntervalKeepAliveInterval的值表示未收到另一方对“保持连接”信号的响应时，系统重复发送“保持连接”信号的频率。在无任何响应的情况下，连续发送“保持连接”信号的次数超过TcpMaxDataRetransmissions（下文将介绍）的值时，将放弃该连接。如果网络环境较差，允许较长的响应时间，则考虑增大该值以减少开销；如果需要尽快验证是否已丢失接收方，则考虑减小该值或TcpMaxDataRetransmissions值。缺省情况下，在未收到响应而重新发送“保持连接”的信号之前，系统会等待1000毫秒（1秒），可以根据具体需求修改，具体操作：浏览至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注册表子键，在Parameters子键下创建或修改名为KeepAliveInterval的REG_DWORD值，为该值设置适当的毫秒数。9. TcpMaxDataRetransmissionsTcpMaxDataRetransmissions的值表示TCP数据重发，系统在现有连接上对无应答的数据段进行重发的次数。如果网络环境很差，可能需要提高该值以保持有效的通信，确保接收方收到数据；如果网络环境很好，或者通常是由于丢失接收方而导致数据的丢失，那么可以减小该值以减少验证接收方是否丢失所花费的时间和开销。缺省情况下，系统会重新发送未返回应答的数据段5次，可以根据具体需求修改，具体操作：浏览至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注册表子键，在Parameters子键下创建或修改名为TcpMaxDataRetransmissions的REG_DWORD值，该值的范围是从0到4294967295，缺省值为5，根据实际情况进行设置。10. TcpMaxConnectRetransmisstionsTcpMaxConnectRetransmisstions的值表示TCP连接重发，TCP退出前重发非确认连接请求（SYN）的次数。对于每次尝试，重发超时是成功重发的两倍。在Windows Server 2003中默认超时次数是2，默认超时时间为3秒（在注册表项TCPInitialRTT中）。速度较慢的WAN连接中超时时间可相应增加，不同环境中可能会有不同的最优化设置，需要在实际环境中测试确定。超时时间不要设置太大否则将不会发生网络连接超时时间。具体操作：浏览至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注册表子键，在Parameters子键下创建或修改名为TcpMaxConnectRetransmisstions的REG_DWORD值，该值的范围是从0到255，缺省值为2，根据实际情况进行设置。然后在Parameters子键下创建或修改名为TCPInitialRTT的REG_DWORD值，同样根据实际情况进行设置。11. TcpAckFrequencyTcpAckFrequency的值表示系统发送应答消息的频率。如果值为2，那么系统将在接收到2个分段之后发送应答，或是在接收到1个分段但在200毫秒内没有接收到任何其他分段的情况下发送应答；如果值为3，那么系统将在接收到3个分段之后发送应答，或是在接收到1个或2个分段但在200毫秒内没有接收到任何其他分段的情况下发送应答，以此类推。如果要通过消除应答延迟来缩短响应时间，那么建议将该值设为1。在此情况下，系统会立即发送对每个分段的应答；如果连接主要用于传输大量数据，而200毫秒的延迟并不重要，那么可以减小该值以降低应答的开销。缺省情况下，系统将该值设为2，即每隔一个分段应答一次。该值的有效范围是0到255，其中0表示使用缺省值2，可以根据具体需求修改，具体操作：浏览至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParametersInterfacesxx（xx由网络适配器决定）注册表子键，在xx子键下创建或修改名为TcpAckFrequency的REG_DWORD值，该值的范围是从1到13，缺省值为2，根据希望每发送几个分段返回一个应答而设置该值，建议百兆网络设为5，千兆网络设为13。https://www.cnblogs.com/larry-luo/p/11064346.html

两将军问题：红蓝两军作战，蓝军战斗力强大，红1军或红2军与其单独作战都打不过蓝军，所以需要红一军与红二军联合对蓝军发起进攻，红军1首先通知红军2明早10点发起总攻，如图1-1，红军2接到消息需要回复“好的红军1，我已经收到你得消息，确认明早10点发动总攻”。因为消息传递路线必须经过蓝军营地，所以双方传递消息的信使很有可能被蓝军俘获。为了确保消息的可靠性，红1、红2双方在发出一个消息之后都想得到对方的消息回执。但是这会导致消息无线循环下去，如图1-2。那么如何解决这个可靠性的问题呢，其实没有办法解决，只要保证双方各自都有一次成功的发送、回执就可以了。两将军问题也存在网络世界里，客户端、服务器建立连接不可能无限的确认下去，只要保证客户端和服务器分别对自己的收、发能力做一次确认即可，如下图。 客户端和服务器分别对自己的收、发能力做一次确认至少需要3次握手。3次握手的具体过程、状态如下：（1）首先客户端和服务器都处于CLOSED状态。（2）服务器处于LISTEN状态，具体为服务器调用Socket、bind、listen函数，进入阻塞状态。（3）客户端发送SYN（同步序列编号），发送完毕客户端进入SYN_SENT状态。（4）服务端收到SYN，发送SYN+ASK，发送完毕进入SYN_RCVD状态。（5）客户端收到服务端发来的SYN+ASK，发送服务端等待的ASK，发送完毕客户端进入ESTABLISHED状态，准备数据传输,到此客户端已经满足了对自己收发能力的一次验证。（6）服务端收到客户端发来的ASK，与客户端一样，到此服务端也已经满足了对自己收发能力的一次验证，所以也进入ESTABLISHED状态，准备数据传输。（7）准备开始传输数据TCP断开连接有两种情况或者说是场景，1 客户端先断开连接，当然也可能是服务器先断开连接，总之是一前一后。 2 双方同时发起断开连接操作。下面分别介绍两种场景：（1）客户端先发起断开连接操作，客户端向服务端发送FIN，发送完毕客户端进入FIN_WAIT_1状态。（2）服务端收到客户端发来的FIN，服务端发送ACK，发送完毕进入CLOSED_WAIT状态。（3）客户端收到服务端的ACK回复，客户端进入FIN_WAIT_2状态，如果后面服务端没有回应客户端，在TCP协议层面来讲，客户端将永远停留在这个状态了，不过还好，操作系统着这块做了处理，有一个超时时间。（4）此时TCP连接进入半关闭状态，即客户端主，服务端从的这条线路已经关闭，不过服务端主，客户端从的这条线路还处于打开状态。（5）服务端向客户端发送FIN，发送完毕，服务端进入LAST_ASK状态。（6）客户端收到服务端的FIN后回复服务端ACK，回复完毕进入TIME_WAIT状态，为什么要进入这个状态？因为第6步是客户端的最后一条回复，服务端很有可能收不到，收不到服务端就会重发，所以客户端还要等待一会。（7）服务端收到客户端的ACK回复之后，不再做响应，回到初始的CLOSED状态，在连接池中等待下一次的复用。（8）客户端保持TIME_WAIT状态，超时之后同样进入CLOSED状态。场景二（1）客户端、服务器双方同时发送FIN，双方同时进入FIN_WAIT_1状态（2）双方都接到了对方的ACK，此时双方都会进入CLOSING状态。（3）双方同时进入TIME_WAIT状态，为什么要进入这个状态而不是直接进入CLOSED状态呢？假设客户端和服务端本次是第X次建立连接、关闭连接。如果立即关闭，随后建立第X+1次连接，建立连接成功之后，第X次的丢包的数据有可能绕了一大圈又回来了，那就会出现数据错误，为了避免这种情况所以要进入TIME_WAIT状态，以保证旧连接的数据不会再回来。（4）TIME_WAIT超时之后，双双进入CLOSED状态。有了上面对TCP连接3次握手4次挥手的介绍，再来理解TCP的状态图就不困难了，无非就是对TCP连接3次握手4次挥手过程的打包概述而已。