TCP 服务器设计：高效稳定的网络架构实践 (tcp 服务器设计)

TCP服务器设计：高效稳定的网络架构实践

网络连接已经成为了现代化的基础设施，而TCP/IP网络协议的普及和广泛应用则是让连接更加实现化和便捷化的重要途径。在TCP/IP架构下，TCP服务器成为了管理连接的重要组成部分，而设计一个高效稳定的TCP服务器则成为了开发者需要面对的重要技术难题。本文将介绍如何设计一个高效稳定的TCP服务器并为大家提供一些实践经验。

一、基础知识

我们需要了解一些基础知识。在TCP/IP协议中，TCP是一种面向连接的协议，而UDP则是一种无连接的协议。TCP服务器可以支持多种协议的网络访问，这些协议可以是HTTP、TP、FTP等。在TCP协议下，连接的建立和维持都需要一定的成本，包括时间和内存耗费。因此，设计高效稳定的TCP服务器必须要考虑这些因素。

二、TCP服务器设计

1、优化基础设施

一个TCP服务器的性能取决于很多方面，从基础设施开始优化是值得投入时间和精力的。保证服务器硬件设施的良好运转（包括带宽、硬盘、内存等）能够为TCP的稳定性和效率提供保障。此外，基础设施的优化还需要考虑网络拓扑结构，采用分布式结构和缓存技术等可以优化TCP服务器的性能。

2、自动伸缩

自动伸缩是提高TCP服务器的使用率和可靠性的重要方式。随着连接的增加和服务器的负载增加，TCP服务器可以自动增加服务器的数量来满足连接的需求。在自动伸缩机制下，TCP服务器需要考虑负载均衡的问题，选择合适的算法进行负载均衡，可以更大程度地提高服务器的性能。

3、优化TCP连接的管理

TCP连接的管理是TCP服务器设计中的关键问题之一。在对TCP连接的管理上，可以采用连接池技术，将连接保存在连接池中，以便快速建立连接；同时，建议采用心跳机制（heartbeat）来监测连接状态，及时判断连接是否存活，优化连接池的管理。

4、应用程序优化

TCP服务器应用程序的优化也是提升TCP服务器性能的关键。在应用程序层面上，尽可能减少数据传输的耗时，使用流媒体技术，对数据传输进行块级处理，以减少网络传输时间，可以大幅提升服务器的效率。

三、实践经验

1、使用Nginx进行反向代理

Nginx作为一款轻量级的Web服务器，采用反向代理的方式可以将请求分发至多台服务器，同时采用缓存机制提高服务器效率，并且能够避免由于单机点故障引发的宕机等不良后果，提高TCP服务器的稳定性。

2、采用异步I/O策略

异步I/O是指在通信过程中数据的输入输出操作不被立即执行，而是放入一个队列中等待操作系统处理。采用异步I/O策略能够避免由于等待I/O操作而阻塞导致的应用程序假死问题，提高服务器性能，避免资源浪费。

3、使用Epoll或Kqueue等高效I/O模型

在Linux和FreeBSD环境中，使用Epoll或Kqueue方式能够显著提高服务器性能，因为它们能够实现高效的事件通知机制，尤其在高用户并发量时性能优势更加突出。

四、

TCP服务器的设计需要考虑基础设施、自动伸缩、TCP连接的管理、应用程序优化等多个方面。新的技术和实践方式的不断涌现，可以为我们提供更多的选择，例如使用反向代理、采用异步I/O策略、使用Epoll等高效I/O模型等。在今后的TCP服务器设计和优化中，我们需要根据不同应用和环境的要求采用适当的技术和实践方式，从而实现高效稳定的TCP服务器架构实践。

相关问题拓展阅读：

• tcp协议通过什么来区分不同的连接
• 编写一个TCP并发服务器端程序，可以把客户端发来的消息回射给客户端

tcp协议通过什么来区分不同的连接

这个我问一个计算机网络的博士他都不会，清毁激我也找不到，初步判断是通过序列号来区分，答袜待我余铅去抓包实验，因为在研究tcp劫持

TCP/IP

不同的计算机系统，就好像语言不同的两个人互相见了面，完全不能交流信息。因而他段漏滑们需要定义一些共通的东西来进行交流，TCP/IP就是为此而生。TCP/IP不是一个协议，而是一个协议族的统称。里面包括了

IP协议

，IMCP协议，

TCP协议

，以及我们更加熟悉的http、ftp、pop3协议等等。电脑有了这些，就好像学会了外语一样，就可以和其搜槐他的计算机终端做自由的交流了。

TCP/IP 层次

应用层(http、ftp、tp) –>

传输层

(TCP、UDP)–>

网络层

(IP)–>

数据链路层

域名系统

:域名系统是一个分布的数据库，它提供将主机名（就是网址啦）转换成

IP地址

的服务。

端口号

(port): 注意，这个号码是用在TCP，UDP上的一个逻辑号码，并不是一个硬件端口，我们平时说把某某端口封掉了，也只是在IP层次把带有这个号码的IP包给过滤掉了而已。

应用编程接口:现在常用的编程接口有socket和TLI。

数据链路层

数据链路层有三个目的：

为IP模块发送和 接收IP数据报。

为ARP模块发送ARP请求和接收ARP应答。

为RARP发送RARP请 求和接收RARP应答

ip大家都听说过。至于ARP和RARP，ARP叫做地址解析协议，是用IP地址换

MAC地址

的一种协议，而RARP则叫做逆地址解析协议.

—

IP 、ARP 、RARP 协议

三者都是在网络层 ，

ARP协议

用来找到目标主机的Ethernet网卡Mac地址，IP则承载要发送的消息。数据链路层可以从ARP得到数据的传送信息，而从IP得到要传输的数据信息。

IP 协议

IP协议是TCP/IP协议的核心，所有的TCP，UDP，IMCP，IGCP的数据都以IP数据格式传输。要注意的是，IP不是可靠的协议，这是说，IP协议没有提供一种数据未传达以后的处理机制－－这被认为是上层协议：TCP或UDP要做的事情。所以这也就出现了TCP是一个可靠的协议，而UDP就没有那么可靠的区别。

协议头

八位的TTL字段，还记得这个字段是做什么的么？这个字段规定该数据包在穿过多少个路由之后才会被抛弃(这里就体现出来IP协议包的不可靠性，它不保证数据被送达)，某个ip数据包每穿过一个路由器，该数据包的TTL数值就会减少1，当该数据包的TTL成为零，它就会被自动抛弃。这个字段的更大值也就是255，也就是说一个协议包也就在路由器里面穿行255次就会被抛弃了，根据系统的不同，这个数字也不一样，一般是32或者是64，Tracerouter这个工具就是用这个原理工作的，tranceroute的-m选项要求更大值是255，也就是握腊因为这个TTL在IP协议里面只有8bit。

现在的ip

版本号

是4，所以也称作IPv4。现在还有IPv6，而且运用也越来越广泛了。

IP路由选择

当一个IP数据包准备好了的时候，IP数据包（或者说是路由器）是如何将数据包送到目的地的呢？它是怎么选择一个合适的路径来”送货”的呢？

最特殊的情况是目的主机和主机直连，那么主机根本不用寻找路由，直接把数据传递过去就可以了。至于是怎么直接传递的，这就要靠ARP协议了。

稍微一般一点的情况是，主机通过若干个路由器(router)和目的主机连接。那么路由器就要通过ip包的信息来为ip包寻找到一个合适的目标来进行传递，比如合适的主机，或者合适的路由。路由器或者主机将会用如下的方式来处理某一个IP数据包

如果IP数据包的TTL（

生命周期

）以到，则该IP数据包就被抛弃。

搜索

路由表

，优先搜索匹配主机，如果能找到和IP地址完全一致的目标主机，则将该包发向目标主机

搜索路由表，如果匹配主机失败，则匹配同子网的路由器，这需要“

子网掩码

(1.3.)”的协助。如果找到路由器，则将该包发向路由器。

搜索路由表，如果匹配同子网路由器失败，则匹配同网号路由器，如果找到路由器，则将该包发向路由器。

搜索路由表，如果以上都失败了，就搜索默认路由，如果默认路由存在，则发包

如果都失败了，就丢掉这个包

这再一次证明了，ip包是不可靠的。因为它不保证送达。

ARP协议

还记得数据链路层的

以太网

的协议中，每一个数据包都有一个MAC地址头么？我们知道每一块以太网卡都有一个MAC地址，这个地址是唯一的，那么IP包是如何知道这个MAC地址的？这就是ARP协议的工作。

ARP（地址解析）协议是一种解析协议，本来主机是完全不知道这个IP对应的是哪个主机的哪个接口，当主机要发送一个IP包的时候，会首先查一下自己的ARP高速缓存（就是一个IP-MAC地址对应表缓存），如果查询的IP－MAC值对不存在，那么主机就向网络发送一个ARP协议广播包，这个广播包里面就有待查询的IP地址，而直接收到这份广播的包的所有主机都会查询自己的IP地址，如果收到广播包的某一个主机发现自己符合条件，那么就准备好一个包含自己的MAC地址的ARP包传送给发送ARP广播的主机，而广播主机拿到ARP包后会更新自己的ARP缓存（就是存放IP-MAC对应表的地方）。发送广播的主机就会用新的ARP缓存数据准备好数据链路层的的数据包发送工作。

arp -a 可以查询自己的arp缓存

这样的高速缓存是有时限的，一般是20分钟（伯克利系统的衍生系统）。

—

ICMP协议

—

UDP 协议

UDP是传输层协议，和TCP协议处于一个分层中，但是与TCP协议不同，

UDP协议

并不提供超时重传，出错重传等功能，也就是说其是不可靠的协议。

1 、UDP 的端口号

由于很多软件需要用到UDP协议，所以UDP协议必须通过某个标志用以区分不同的程序所需要的数据包。端口号的功能就在于此，例如某一个UDP程序A在系统中注册了3000端口，那么，以后从外面传进来的目的端口号为3000的UDP包都会交给该程序。端口号理论上可以有2^16这么多。因为它的长度是16个bit

2 、UDP 的检验和

这是一个可选的选项，并不是所有的系统都对UDP数据包加以检验和数据(相对TCP协议的必须来说)，但是RFC中标准要求，发送端应该计算检验和。

UDP检验和覆盖UDP协议头和数据，这和IP的检验和是不同的，IP协议的检验和只是覆盖IP数据头，并不覆盖所有的数据。UDP和TCP都包含一个伪首部，这是为了计算检验和而摄制的。伪首部甚至还包含IP地址这样的IP协议里面都有的信息，目的是让UDP两次检查数据是否已经正确到达目的地。如果发送端没有打开检验和选项，而接收端计算检验和有差错，那么UDP数据将会被悄悄的丢掉（不保证送达），而不产生任何差错报文。

3 、UDP 的长度

UDP可以很长很长，可以有65535字节那么长。但是一般网络在传送的时候，一次一般传送不了那么长的协议（涉及到MTU的问题），就只好对数据分片，当然，这些是对UDP等上级协议透明的，UDP不需要关心IP协议层对数据如何分片。

4 、IP 分片

IP在从上层接到数据以后，要根据IP地址来判断从那个接口发送数据（通过选路），并进行MTU的查询，如果数据大小超过MTU就进行数据分片。数据的分片是对上层和下层透明，而数据也只是到达目的地还会被重新组装，不过不用担心，IP层提供了足够的信息进行数据的再组装。

在IP头里面，16bit识别号唯一记录了一个IP包的ID,具有同一个ID的IP片将会被重新组装；而13位片偏移则记录了某IP片相对整个包的位置；而这两个表示中间的3bit标志则标示着该分片后面是否还有新的分片。这三个标示就组成了IP分片的所有信息，接受方就可以利用这些信息对IP数据进行重新组织（就算是后面的分片比前面的分片先到，这些信息也是足够了）。

因为分片技术在网络上被经常的使用，所以伪造IP分片包进行流氓攻击的软件和人也就层出不穷。

5 、ICMP源站抑制差错

当目标主机的处理速度赶不上数据接收的速度，因为接受主机的IP层缓存会被占满，所以主机就会发出一个“我受不了”的一个ICMP报文。

—

单播广播和多播

单播

单播是说，对特定的主机进行数据传送。例如给某一个主机发送IP数据包。这时候，数据链路层给出的数据头里面是非常具体的目的地址，对于以太网来 说，就是网卡的MAC地址（不是FF-FF-FF-FF-FF-FF这样的地址）。现在的具有路由功能的主机应该可以将单播数据定向转发，而目的主机的网 络接口则可以过滤掉和自己MAC地址不一致的数据。

广播

广播是主机针对某一个网络上的所有主机发送数据包。这个网络可能是网络，可能是子网，还可能是所有的子网。如果是网络，例如A类网址的广播就是 netid.255.255.255，如果是子网，则是netid.netid.subnetid.255；如果是所有的子网（B类IP）则是则是 netid.netid.255.255。广播所用的MAC地址FF-FF-FF-FF-FF-FF。网络内所有的主机都会收到这个广播数据，网卡只要把 MAC地址为FF-FF-FF-FF-FF-FF的数据交给内核就可以了。一般说来ARP，或者路由协议RIP应该是以广播的形式播发的。

多播

可以说广播是多播的特例，多播就是给一组特定的主机（多播组）发送数据，这样，数据的播发范围会小一些(实际上播发的范围一点也没有变小)，多播的MAC地址是更高字节的低位为一，例 如-00。多播组的地址是D类IP，规定是224.0.0.0-239.255.255.255。

虽然多播比较特殊，但是究其原理，多播的数据还是要通过数据链路层进行MAC地址绑定然后进行发送。所以一个以太网卡在绑定了一个多播IP地址之后，必 定还要绑定一个多播的MAC地址，才能使得其可以像单播那样工作。这个多播的IP和多播MAC地址有一个对应的算法，在书的p133到p134之间。可以看到 这个对应不是一一对应的，主机还是要对多播数据进行过滤。

—

TCP

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窗口协议，如果处理鼠标事件时还是用这个算法，那么“延迟”可就非常大了。

2.TCP的成块数据流

对于FTP这样对于数据吞吐量有较高要求的要求，将总是希望每次尽量多的发送数据到对方主机，就算是有点“延迟”也无所谓。TCP也提供了一整套的策略来支持这样的需求。TCP协议中有16个bit表示“窗口”的大小，这是这些策略的核心。

2.1.传输数据时ACK的问题

在解释滑动窗口前，需要看看ACK的应答策略，一般来说，发送端发送一个TCP数据报，那么接收端就应该发送一个ACK数据报。但是事实上却不是这样，发送端将会连续发送数据尽量填满接受方的缓冲区，而接受方对这些数据只要发送一个ACK报文来回应就可以了，这就是ACK的累积特性，这个特性大大减少了发送端和接收端的负担。

2.2.滑动窗口

滑动窗口本质上是描述接受方的TCP数据报缓冲区大小的数据，发送方根据这个数据来计算自己最多能发送多长的数据。如果发送方收到接受方的窗口大小为0的TCP数据报，那么发送方将停止发送数据，等到接受方发送窗口大小不为0的数据报的到来。

2.3.数据拥塞

上面的策略用于局域网内传输还可以，但是用在广域网中就可能会出现问题，更大的问题就是当传输时出现了瓶颈（比如说一定要经过一个slip低速链路）所产生的大量数据堵塞问题（拥塞），为了解决这个问题，TCP发送方需要确认连接双方的线路的数据更大吞吐量是多少。这，就是所谓的拥塞窗口。

拥塞窗口的原理很简单，TCP发送方首先发送一个数据报，然后等待对方的回应，得到回应后就把这个窗口的大小加倍，然后连续发送两个数据报，等到对方回应以后，再把这个窗口加倍（先是2的指数倍，到一定程度后就变成现行增长，这就是所谓的慢启动），发送更多的数据报，直到出现超时错误，这样，发送端就了解到了通信双方的线路承载能力，也就确定了拥塞窗口的大小，发送方就用这个拥塞窗口的大小发送数据。要观察这个现象是非常容易的，我们一般在下载数据的时候，速度都是慢慢“冲起来的”

—

TCP的超时和重传

超时重传是TCP协议保证数据可靠性的另一个重要机制，其原理是在发送某一个数据以后就开启一个计时器，在一定时间内如果没有得到发送的数据报的ACK报文，那么就重新发送数据，直到发送成功为止。

超时

超时时间的计算是超时的核心部分，TCP要求这个算法能大致估计出当前的网络状况，虽然这确实很困难。要求精确的原因有两个：(1)定时长久会造成网络利用率不高。(2)定时太短会造成多次重传，使得网络阻塞。所以，书中给出了一套经验公式，和其他的保证计时器准确的措施。

计时器的使用

一个连接中，有且仅有一个测量定时器被使用。也就是说，如果TCP连续发出3组数据，只有一组数据会被测量。

ACK数据报不会被测量，原因很简单，没有ACK的ACK回应可以供结束定时器测量。

重传

前面曾经提到过，数据在传输的时候不能只使用一个窗口协议，我们还需要有一个拥塞窗口来控制数据的流量，使得数据不会一下子都跑到网路中引起“拥塞”。也曾经提到过，拥塞窗口最初使用指数增长的速度来增加自身的窗口，直到发生超时重传，再进行一次微调。但是没有提到，如何进行微调，拥塞避免算法和慢启动门限就是为此而生。

所谓的慢启动门限就是说，当拥塞窗口超过这个门限的时候，就使用拥塞避免算法，而在门限以内就采用慢启动算法。所以这个标准才叫做门限，通常，拥塞窗口记做cwnd，慢启动门限记做ssthresh。下面我们来看看拥塞避免和慢启动是怎么一起工作的

算法概要

对一个给定的连接，初始化cwnd为1个报文段，ssthresh为65535个字节。

TCP输出例程的输出不能超过cwnd和接收方通告窗口的大小。拥塞避免是发送方使用 的流量控制，而通告窗口则是接收方进行的流量控制。前者是发送方感受到的网络拥塞的估 计，而后者则与接收方在该连接上的可用缓存大小有关。

当拥塞发生时（超时或收到重复确认），ssthresh被设置为当前窗口大小的一半（cwnd 和接收方通告窗口大小的最小值，但最少为2个报文段）。此外，如果是超时引起了拥塞，则 cwnd被设置为1个报文段（这就是慢启动）。

当新的数据被对方确认时，就增加cwnd，但增加的方法依赖于我们是否正在进行慢启 动或拥塞避免。如果cwnd小于或等于ssthresh，则正在进行慢启动，否则正在进行拥塞避免。 慢启动一直持续到我们回到当拥塞发生时所处位置的半时候才停止（因为我们记录了在步骤2 中给我们制造麻烦的窗口大小的一半），然后转为执行拥塞避免。

快速重传和快速恢复算法

这是数据丢包的情况下给出的一种修补机制。一般来说，重传发生在超时之后，但是如果发送端接受到3个以上的重复ACK的情况下，就应该意识到，数据丢了，需要重新传递。这个机制是不需要等到重传定时器溢出的，所以叫做快速重传，而重新传递以后，因为走的不是慢启动而是拥塞避免算法，所以这又叫做快速恢复算法。流程如下：

当收到第3个重复的ACK时，将ssthresh设置为当前拥塞窗口cwnd的一半。重传丢失的 报文段。设置cwnd为ssthresh加上3倍的报文段大小。

每次收到另一个重复的ACK时， cwnd增加1个报文段大小并发送1个分组（如果新的 cwnd允许发送）。

当下一个确认新数据的ACK到达时，设置cwnd为ssthresh（在第1步中设置的值）。这个 ACK应该是在进行重传后的一个往返时间内对步骤1中重传的确认。另外，这个ACK也应该 是对丢失的分组和收到的第1个重复的ACK之间的所有中间报文段的确认。这一步采用的是拥 塞避免，因为当分组丢失时我们将当前的速率减半。

TCP的其它定时器

坚持定时器

用于防止通告窗口为0以后双方互相等待死锁的情况

坚持定时器的原理是简单的，当TCP服务器收到了客户端的0滑动窗口报文的时候，就启动一个定时器来计时，并在定时器溢出的时候向向客户端查询窗口是否已经增大，如果得到非零的窗口就重新开始发送数据，如果得到0窗口就再开一个新的定时器准备下一次查询。通过观察可以得知，TCP的坚持定时器使用1，2，4，8，16……64秒这样的普通指数退避序列来作为每一次的溢出时间。

2.保活定时器

保活定时器更加的简单，还记得FTP或者Http服务器都有Sesstion Time机制么？因为TCP是面向连接的，所以就会出现只连接不传送数据的“半开放连接”，服务器当然要检测到这种连接并且在某些情况下释放这种连接，这就是保活定时器的作用。其时限根据服务器的实现不同而不通。另外要提到的是，当其中一端如果崩溃并重新启动的情况下，如果收到该端“前生”的保活探察，则要发送一个RST数据报文帮助另一端结束连接。

编写一个TCP并发服务器端程序，可以把客户端发来的消息回射给客户端

简单的写了一晌渣败下，没有加注释，应该很好理解，满意的梁庆话请采纳

#include

#include

#include

void *thread(void *st);

int main(int argc, char *argv)

{

pthread_t tid;

int ret, fd;

struct sockaddr_in info;

fd = socket(AF_INET, SOCK_STREAM, 0);

if(fd

goto socket_error;

{

int var = 1;

setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &var, sizeof(var));;

}

info.sin_family = AF_INET;

info.sin_port = htons(80);

info.sin_addr.s_addr = 0;

ret = bind(fd, (void *)&info, sizeof(info));

if(ret)

goto bind_error;

ret = listen(fd, 10);

if(ret)

goto listen_error;

while(1)

{

clientfd = accept(fd, NULL, NULL);

pthread_create(&tid, NULL, thread, (void *)clientfd);

}

return 0;

socket_error:

printf(“socket error!\n”);

return -1;

bind_error:

printf(“bind error!\n”);

return -2;

lister_error:

printf(“lister error!\n”);

return -2;

}

void *thread(void *st)

{

int ret, rd;

char buf;

int clientfd = (int)st;

rd = read(clientfd, buf, sizeof(buf));

if(rd

{

printf(“read error!\n”)

return;;

}

write(clientfd, “宴颤shou dao!”, 9);

close(clientfd);

关于tcp 服务器设计的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。