tcp server

#include <stdio.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <sys/types.h>
#include <string.h>

int main(int argc, char* argv) {

    int sock = socket(AF_INET, SOCK_STREAM, 0);

    struct sockaddr_in servaddr;
    servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
    servaddr.sin_family = AF_INET;
    servaddr.sin_port = htons(9999);

    bind(sock, (struct sockaddr*)&servaddr, sizeof(struct sockaddr));
    listen(sock, 10);

    struct sockaddr_in clientaddr;
    socklen_t len = sizeof(clientaddr);

    while (1) {

        int fd = accept(sock, (struct sockaddr*)&clientaddr, &len);
        printf("accept %d\n", fd);
    }

    return 0;
}

https://imagehyj.oss-cn-hangzhou.aliyuncs.com/blog/20240801105613.png

  • 可以连接上就OK了，大概看一下搭建Server的流程。

什么是tcp

TCP（Transmission ControlProtocol）是一种常见的网络传输协议，用于在互联网上可靠地传输数据。它位于网络协议栈的传输层，负责将数据分割成合适大小的数据段，并确保这些数据段按顺序到达目标设备。TCP提供了错误检测、重传机制和流量控制等功能，以确保可靠性和有序性。它是基于连接的协议，意味着在通信之前需要建立一个双向的连接，通信结束后再断开连接。

tcp数据包

https://imagehyj.oss-cn-hangzhou.aliyuncs.com/blog/20240801151210.png

https://imagehyj.oss-cn-hangzhou.aliyuncs.com/blog/20240801151317.png

  1. 源始端口16位，范围当然是0-65535啦。

  2. 目的端口，同上。

  3. （seq）数据序号32位，TCP为发送的每个字节都编一个号码，这里存储当前数据包数据第一个字节的序号。

  4. (ack)确认序号32位，为了安全，TCP告诉接受者希望他下次接到数据包的第一个字节的序号。

  5. 偏移4位，类似IP，表明数据距包头有多少个32位。

  6. 保留6位，未使用，应置零。

  7. U(代表图中字母)紧急比特URG—当URG＝1时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送(相当于高优先级的数据)。

  8. A(代表图中字母)确认比特ACK—只有当ACK＝1时确认号字段才有效。当ACK＝0时，确认号无效。参考TCP三次握手。

  9. R(代表图中字母)复位比特RST(Reset)—当RST＝1时，表明TCP连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。参考TCP三次握手。

  10. S(代表图中字母)同步比特SYN—同步比特SYN置为1，就表示这是一个连接请求或连接接受报文。参考TCP三次握手

  11. F(代表图中字母)终止比特FIN(FINal)—用来释放一个连接。当FIN＝1时，表明此报文段的发送端的数据已发送完毕，并要求释放运输连接。

  12. 窗口字段16位，窗口字段用来控制对方发送的数据量，单位为字节。TCP连接的一端根据设置的缓存空间大小确定自己的接收窗口大小，然后通知对方以确定对方的发送窗口的上限。

  13. 包校验和16位，包括首部和数据这两部分。在计算检验和时，要在TCP报文段的前面加上12字节的伪首部。

  14. 紧急指针16位，紧急指针指出在本报文段中的紧急数据的最后一个字节的序号。

  15. 可选选项24位，类似IP，是可选选项。

  16. 填充8位，使选项凑足32位。

  17. 用户数据……

tcp状态迁移图

https://imagehyj.oss-cn-hangzhou.aliyuncs.com/blog/d75e0561f82e73da39dd1283e3b6c890.jpeg

Clinet连接Server三次握手

当Client端调用socket函数调用时，相当于Client端产生了一个处于Closed状态的套接字。

  1. 第一次握手SYN：Client端又调用connect函数调用，系统为Client随机分配一个端口，连同传入connect中的参数(Server的IP和端口)，这就形成了一个连接四元组，客户端发送一个带SYN标志的TCP报文到服务器。这是三次握手过程中的报文1。connect调用让Client端的socket处于SYN_SENT状态，等待服务器确认；SYN：同步序列编号(Synchronize Sequence Numbers)。

  2. 第二次握手SYN+ACK： 服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；

  3. 第三次握手ACK：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户器和客务器进入ESTABLISHED状态，完成三次握手。连接已经可以进行读写操作。

一个完整的三次握手也就是： 请求—应答—再次确认。

https://imagehyj.oss-cn-hangzhou.aliyuncs.com/blog/20240801152142.png

Server的三次握手

当Server端调用socket函数调用时，相当于Server端产生了一个处于Closed状态的监听套接字

Server端调用bind操作，将监听套接字与指定的地址和端口关联，然后又调用listen函数，系统会为其分配未完成队列和完成队列，此时的监听套接字可以接受Client的连接，监听套接字状态处于LISTEN状态。

当Server端调用accept操作时，会从完成队列中取出一个已经完成的client连接，同时在server这段会产生一个会话套接字，用于和client端套接字的通信，这个会话套接字的状态是ESTABLISH。

从图中可以看出，当客户端调用connect时，触发了连接请求，向服务器发送了SYN J包，这时connect进入阻塞状态；服务器监听到连接请求，即收到SYN J包，调用accept函数接收请求向客户端发送SYN K ，ACK J+1，这时accept进入阻塞状态；客户端收到服务器的SYN K ，ACK J+1之后，这时connect返回，并对SYN K进行确认；服务器收到ACK K+1时，accept返回，至此三次握手完毕，连接建立。

建立连接的具体状态

  1. LISTENING：侦听来自远方的TCP端口的连接请求.

首先服务端需要打开一个socket进行监听，状态为LISTEN。

有提供某种服务才会处于LISTENING状态，TCP状态变化就是某个端口的状态变化，提供一个服务就打开一个端口，例如：提供www服务默认开的是80端口，提供ftp服务默认的端口为21，当提供的服务没有被连接时就处于LISTENING状态。FTP服务启动后首先处于侦听（LISTENING）状态。处于侦听LISTENING状态时，该端口是开放的，等待连接，但还没有被连接。就像你房子的门已经敞开的，但还没有人进来。

看LISTENING状态最主要的是看本机开了哪些端口，这些端口都是哪个程序开的，关闭不必要的端口是保证安全的一个非常重要的方面，服务端口都对应一个服务（应用程序），停止该服务就关闭了该端口，例如要关闭21端口只要停止IIS服务中的FTP服务即可。关于这方面的知识请参阅其它文章。

如果你不幸中了服务端口的木马，木马也开个端口处于LISTENING状态。

  1. SYN-SENT：客户端SYN_SENT状态

再发送连接请求后等待匹配的连接请求:客户端通过应用程序调用connect进行active open.于是客户端tcp发送一个SYN以请求建立一个连接.之后状态置为SYN_SENT. /The socket is actively attempting to establish a connection. 在发送连接请求后等待匹配的连接请求 / 当请求连接时客户端首先要发送同步信号给要访问的机器，此时状态为SYN_SENT，如果连接成功了就变为ESTABLISHED，正常情况下SYN_SENT状态非常短暂。例如要访问网站http://www.baidu.com,如果是正常连接的话，用TCPView观察IEXPLORE.EXE（IE）建立的连接会发现很快从SYNSENT变为ESTABLISHED，表示连接成功。SYN_SENT状态快的也许看不到。_ 如果发现有很多SYN_SENT出现，那一般有这么几种情况，一是你要访问的网站不存在或线路不好，二是用扫描软件扫描一个网段的机器，也会出出现很多SYN_SENT，另外就是可能中了病毒了，例如中了"冲击波”，病毒发作时会扫描其它机器，这样会有很多SYN_SENT出现。

  1. SYN-RECEIVED：服务器端握手状态SYN_RCVD

再收到和发送一个连接请求后等待对方对连接请求的确认

当服务器收到客户端发送的同步信号时，将标志位ACK和SYN置1发送给客户端，此时服务器端处于SYN_RCVD状态，如果连接成功了就变为ESTABLISHED，正常情况下SYN_RCVD状态非常短暂。

如果发现有很多SYN_RCVD状态，那你的机器有可能被SYN Flood的DoS(拒绝服务攻击)攻击了。

SYN Flood的攻击原理是：

在进行三次握手时，攻击软件向被攻击的服务器发送SYN连接请求（握手的第一步），但是这个地址是伪造的，如攻击软件随机伪造了51.133.163.104、65.158.99.152等等地址。服务器在收到连接请求时将标志位ACK和SYN置1发送给客户端（握手的第二步），但是这些客户端的IP地址都是伪造的，服务器根本找不到客户机，也就是说握手的第三步不可能完成。

这种情况下服务器端一般会重试（再次发送SYN+ACK给客户端）并等待一段时间后丢弃这个未完成的连接，这段时间的长度我们称为SYN Timeout，一般来说这个时间是分钟的数量级（大约为30秒-2分钟）；一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题，但如果有一个恶意的攻击者大量模拟这种情况，服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源—-数以万计的半连接，即使是简单的保存并遍历也会消耗非常多的CPU时间和内存，何况还要不断对这个列表中的IP进行SYN+ACK的重试。此时从正常客户的角度看来，服务器失去响应，这种情况我们称做：服务器端受到了SYN Flood攻击（SYN洪水攻击）

  1. ESTABLISHED：代表一个打开的连接。

ESTABLISHED状态是表示两台机器正在传输数据，观察这个状态最主要的就是看哪个程序正在处于ESTABLISHED状态。

服务器出现很多ESTABLISHED状态： netstat -nat |grep 9502或者使用lsof -i:9502可以检测到。

当客户端未主动close的时候就断开连接：即客户端发送的FIN丢失或未发送:

这时候若客户端断开的时候发送了FIN包，则服务端将会处于CLOSE_WAIT状态；

这时候若客户端断开的时候未发送FIN包，则服务端处还是显示ESTABLISHED状态；

结果客户端重新连接服务器。

而新连接上来的客户端（也就是刚才断掉的重新连上来了）在服务端肯定是ESTABLISHED; 如果客户端重复的上演这种情况，那么服务端将会出现大量的假的ESTABLISHED连接和CLOSE_WAIT连接。

最终结果就是新的其他客户端无法连接上来，但是利用netstat还是能看到一条连接已经建立，并显示ESTABLISHED，但始终无法进入程序代码。

关闭连接的状态

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

  1. 四次挥手关闭连接

建立一个连接需要三次握手，而终止一个连接要经过四次握手，这是由TCP的半关闭(half-close)造成的，如图：

https://imagehyj.oss-cn-hangzhou.aliyuncs.com/blog/20240801153012.png

  1. 客户端发送一个FIN: 用来关闭客户A到服务器B的数据传送,当client想要关闭它与server之间的连接。client（某个应用进程）首先调用close主动关闭连接，这时TCP发送一个FIN M；client端处于FIN_WAIT1状态。

  2. 服务器确认客户端FIN: 当server端接收到FIN M之后，执行被动关闭。对这个FIN进行确认，返回给client ACK。确认序号为收到的序号加1（报文段5）。和SYN一样，一个FIN将占用一个序号。当server端返回给client ACK后，client处于FIN_WAIT2状态，server处于CLOSE_WAIT状态。它的接收也作为文件结束符传递给应用进程，因为FIN的接收 意味着应用进程在相应的连接上再也接收不到额外数据；

  3. 服务器B发送一个FIN关闭与客户端A的连接: 一段时间之后，当server端检测到client端的关闭操作(read返回为0)。接收到文件结束符的server端调用close关闭它的socket。这导致server端的TCP也发送一个FIN N；此时server的状态为LAST_ACK。

  4. 客户端A发回ACK报文确认: 当client收到来自server的FIN后 。 client端的套接字处于TIME_WAIT状态，它会向server端再发送一个ack确认，此时server端收到ack确认后，此套接字处于CLOSED状态。

具体状态

  1. FIN-WAIT-1：

等待远程TCP连接中断请求，或先前的连接中断请求的确认

主动关闭(active close)端应用程序调用close，于是其TCP发出FIN请求主动关闭连接，之后进入FIN_WAIT1状态./ The socket is closed, and the connection is shutting down. 等待远程TCP的连接中断请求，或先前的连接中断请求的确认 /

如果服务器出现shutdown再重启，使用netstat -nat查看，就会看到很多FIN-WAIT-1的状态。就是因为服务器当前有很多客户端连接，直接关闭服务器后，无法接收到客户端的ACK。

  1. FIN-WAIT-2：从远程TCP等待连接中断请求

主动关闭端接到ACK后，就进入了FIN-WAIT-2 ./ Connection is closed, and the socket is waiting for a shutdown from the remote end. 从远程TCP等待连接中断请求 /

这就是著名的半关闭的状态了，这是在关闭连接时，客户端和服务器两次握手之后的状态。在这个状态下，应用程序还有接受数据的能力，但是已经无法发送数据，但是也有一种可能是，客户端一直处于FIN_WAIT_2状态，而服务器则一直处于WAIT_CLOSE状态，而直到应用层来决定关闭这个状态。

  1. CLOSE-WAIT：等待从本地用户发来的连接中断请求

被动关闭(passive close)端TCP接到FIN后，就发出ACK以回应FIN请求(它的接收也作为文件结束符传递给上层应用程序),并进入CLOSE_WAIT. / The remote end has shut down, waiting for the socket to close. 等待从本地用户发来的连接中断请求 /

  1. CLOSING：等待远程TCP对连接中断的确认

比较少见./ Both sockets are shut down but we still don't have all our data sent. 等待远程TCP对连接中断的确认 /

实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当一方发送FIN报文后，按理来说是应该先收到（或同时收到）对方的ACK报文，再收到对方的FIN报文。但是CLOSING状态表示一方发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢？

有两种情况可能导致这种状态：

其一，如果双方几乎在同时关闭连接，那么就可能出现双方同时发送FIN包的情况；

其二，如果ACK包丢失而对方的FIN包很快发出，也会出现FIN先于ACK到达。

  1. LAST-ACK：等待原来的发向远程TCP的连接中断请求的确认

被动关闭端一段时间后，接收到文件结束符的应用程序将调用CLOSE关闭连接。这导致它的TCP也发送一个 FIN,等待对方的ACK.就进入了LAST-ACK . / The remote end has shut down, and the socket is closed. Waiting for acknowledgement. 等待原来发向远程TCP的连接中断请求的确认 /

使用并发压力测试的时候，突然断开压力测试客户端，服务器会看到很多LAST-ACK。

  1. TIME-WAIT：等待足够的时间以确保远程TCP接收到连接中断请求的确认

在主动关闭端接收到FIN后，TCP就发送ACK包，并进入TIME-WAIT状态。/ The socket is waiting after close to handle packets still in the network.等待足够的时间以确保远程TCP接收到连接中断请求的确认 /

TIME_WAIT等待状态，这个状态又叫做2MSL状态，说的是在TIME_WAIT2发送了最后一个ACK数据报以后，要进入TIME_WAIT状态，这个状态是防止最后一次握手的数据报没有传送到对方那里而准备的（注意这不是四次握手，这是第四次握手的保险状态）。这个状态在很大程度上保证了双方都可以正常结束。

由于插口的2MSL状态（插口是IP和端口对的意思，socket），使得应用程序在2MSL时间内是无法再次使用同一个插口的，对于客户程序还好一些，但是对于服务程序，例如httpd，它总是要使用同一个端口来进行服务，而在2MSL时间内，启动httpd就会出现错误（插口被使用）。为了避免这个错误，服务器给出了一个平静时间的概念，这是说在2MSL时间内，虽然可以重新启动服务器，但是这个服务器还是要平静的等待2MSL时间的过去才能进行下一次连接。

  1. CLOSED：没有任何连接状态

被动关闭端在接受到ACK包后，就进入了closed的状态。连接结束./* The socket is not being used. 没有任何连接状态。