作者：@小萌新
专栏：@网络
作者简介：大二学生希望能和大家一起进步
本篇博客简介：补充下对于TCP协议的各种理解

TCP协议相关实验

TCP相关试验
- 理解CLOSE_WAIT状态
- 理解TIME_WAIT状态
- 解决TIME_WAIT状态引起的bind失败的方法
- 理解listen的第二个参数
- SYN洪水攻击
TCP和UDP
- TCP和UDP协议对比
- 用UDP实现可靠传输（经典面试题）

TCP相关试验

理解CLOSE_WAIT状态

我们要理解CLOSE_WAIT状态首先要知道什么时候会出现CLOSE_WAIT状态

在这里插入图片描述

当我们的客户端和服务器通信的时候客户端调用close函数关闭其文件描述符此时客户端在底层就会像服务器发送FIN报文服务器给予FIN报文响应的ACK报文之后就会变成CLOSE_WAIT状态而客户端会在第一次发送FIN报文的时候变为FIN_WAIT1状态在收到ACK报文后变为FIN_WAIT2状态

在这里插入图片描述

我们可以编写一个简单的TCP服务器来模拟出该现象不过事实上我们只需要写出服务器的代码就可以了客户端的代码我们可以使用一些现成的工具比如说TELNET

服务器代码如下

  #include <iostream>    
  #include <cstring>    
  #include <unistd.h>    
  #include <sys/socket.h>    
  #include <sys/types.h>    
  #include <arpa/inet.h>    
  #include <netinet/in.h>    
  #include <pthread.h>    
  using namespace std;    
      
  const int PORT = 8081;    
  const int NUM = 5;    
      
      
  void* RUN(void* arg)    
  {    
    pthread_detach(pthread_self());    
    int fd = *(int*)arg;    
    delete arg;                                                                                                                                                                                                                                                                                                                                                                                                                                              
    while(1)    
    {    
      cout << "sockfd" << fd << "is severing the client" << endl;    
      sleep(1);    
    }    
      
    return nullptr;    
  }    
      
      
      
      
  int main()    
  {    
    int listen_socket = socket(AF_INET , SOCK_STREAM , 0);    
    if (listen_socket < 0)    
    {    
      cerr << "listen_socket error" << endl;    
      exit(1);    
    }    
      
    struct sockaddr_in local;    
    memset(&local , '\0' , sizeof(local));    
    local.sin_family = AF_INET;    
    local.sin_port = htons(PORT);    
    local.sin_addr.s_addr =  INADDR_ANY;    
      
    if (bind(listen_socket , (struct sockaddr*)&local , sizeof(local)) < 0)    
    {    
      cerr << "bind error" << endl;    
      exit(2);    
    }    
      
    if(listen(listen_socket , NUM) < 0)    
    {    
      cerr << "listen error" << endl;    
      exit(3);    
    }    
      
    // peer     
    struct sockaddr_in peer;    
    memset(&peer , '\0' , sizeof(peer));    
    socklen_t len = sizeof(peer);    
      
    for(;;)    
    {    
      int sockfd = accept(listen_socket , (struct sockaddr*)&peer , &len);    
      if (sockfd < 0)    
      {    
        cerr << "accept error" << endl;    
        continue;    
      }    
      
      cout << "get a new linl:" << endl;    
      int* p = new int(sockfd);    
      
      pthread_t tid;    
      pthread_create(&tid , nullptr , RUN , (void*)p);    
    }    
      
      
    return 0;    
  }

我们使用netstat查看可以发现两条连接一条是客户端的连接一条是服务器的连接

在这里插入图片描述

当我们现在将Telnet推出后客户端维护的连接状态会变为FIN_WAIT2 (因为它调用close函数到收到响应这段时间太短了以至于我们捕捉不到FIN_WAIT1状态) 服务器的状态就会变为CLOSE_WAIT状态因为我们在内部没有调用close函数所以说服务器不会发起最后的第三次挥手
在这里插入图片描述

理解TIME_WAIT状态

当客户端和服务器进行通信的时候客户端调用close函数关闭对应的文件描述符如果服务器收到后也调用close函数进行了关闭那么此时双方将正常完成四次挥手

但是主动发起四次挥手的一方在四次挥手之后并不会立即进入COLSED状态而是会短暂的进入TIME_WAIT状态中等待一段时间

我们继续刚刚的试验由于telnet推出后服务器没有调用close函数所以说客户端的变为了TIME_WAIT 服务器的状态变为了CLOSE_WAIT

之后如果我们想要见到TIME_WAIT状态我们就只需要方服务器调用close函数就可以但是我们在服务器端的源码中并没有调用close函数所以说我们要想办法关闭服务器打开的文件描述符

我们在前面一篇博客 TCP协议详解中说明了TCP连接异常断开的几种情况其中我们说过如果进程崩溃那么其实是和正常完成四次挥手没有区别的而进程崩溃实际上就是操作系统给进行发送了信号所以说我只需要我们使用键盘让OS向该进程发送信号就能够模拟服务器正常调用close函数的情况

再刨根问底一点为什么操作系统向进程发送信号之后就相当于会调用close函数呢？这里其实是因为文件描述符的生命周期是随进程的而进程在被操作系统杀死后操作系统会回收资源这些资源中肯定就包括文件描述符了

所以说此时我们先让telnet退出紧接着让服务器退出就能见到TIME_WAIT状态了

在这里插入图片描述

解决TIME_WAIT状态引起的bind失败的方法

我们在前面介绍过四次挥手的时候主动发起挥手一方在四次挥手结束的时候会进入TIME_WAIT状态一段时间

如果服务器在有客户端的情况下主动退出了就相当于是服务器先进行了四次挥手那么服务器就将要进入TIME_WAIT一段时间

如果我们此时想要重新启动服务器绑定该端口号我们会发现我们绑定失败了

在这里插入图片描述

这是因为在TIME_WAIT期间这个连接并没有被完全释放这也就意味着我们的端口是被占用着的此时服务器想要继续绑定该端口号就只能等待TIME_WAIT时间结束

当时我们服务器崩溃时最重要的就是让服务器重新启动并且是绑定原来的端口号（因为一般一些服务的端口号都是固定的如果你修改了端口号的话在网络中别人可能就不知道你了）如果想要让服务器崩溃后在TIME_WAIT期间也能立马重新启动需要让服务器在调用socket函数创建套接字后继续调用setsockopt函数设置端口复用这也是编写服务器代码时的推荐做法

setsockopt函数

setsockopt函数可以设置端口复用该函数的函数原型如下：

int setsockopt(int sockfd, int level, int optname, const void *optval, socklen_t optlen);

返回值说明：

设置成功返回0 失败返回-1 同时错误码会被设置

参数说明：

sockfd：需要设置的套接字对应的文件描述符
level：被设置选项的层次比如在套接字层设置选项对应就是SOL_SOCKET
optname：需要设置的选项该选项的可取值与设置的level参数有关
optval：指向存放选项待设置的新值的指针
optlen：待设置的新值的长度

我们这里要设置的就是监听套接字将监听套接字在套接字层设置端口复用选项SO_REUSEADDR 该选项设置为非零值表示开启端口复用

int opt = 1;
setsockopt(listen_sock, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));

在这里插入图片描述

当我们主动发送信号让服务器崩溃之后我们立刻再次启动服务器我们发现此时就不会出现bind error错误了

理解listen的第二个参数

在我们编写TCP套接字服务器的时候在进行了套接字的创建和绑定之后需要调用listen函数将服务器变为监听状态在这之后我们就能使用accept函数建立连接了

我们在调用listen函数的时候需要输入两个参数第一个参数是我们要设置为监听状态的套接字第二个参数是一个数字它表示服务器可以建立的最大连接数

下面我们会通过一个试验来试验下listen的第二个参数是不是这个意思试验步骤如下：

首先编写tcp套接字的服务器代码关于我们这次的代码我们只需要创建套接字绑定监听但是服务器初始化之后我们不调用accept函数建立连接
为了方便验证我们这里将listen的第二个参数设置为2

服务器代码如下

#include <iostream>    
using namespace std;    
#include <cstring>    
#include <unistd.h>    
#include <sys/types.h>    
#include <sys/socket.h>    
#include <arpa/inet.h>    
#include <netinet/in.h>    
#include <pthread.h>    
using namespace std;    
    
    
int main()    
{    
  // create socket     
  int listen_sockfd = socket(AF_INET , SOCK_STREAM , 0);    
  if (listen_sockfd < 0 )    
  {    
    cerr << "socket error" << endl;    
    exit(1);    
  }    
    
  int opt = 1;    
  setsockopt(listen_sockfd , SOL_SOCKET , SO_REUSEADDR , &opt , sizeof(opt));    
    
  // bind     
  struct sockaddr_in local;    
  memset(&local , '\0' , sizeof(local));    
  local.sin_family = AF_INET;    
  local.sin_port = htons(8081);    
  local.sin_addr.s_addr = INADDR_ANY;    
    
  if (bind(listen_sockfd , (struct sockaddr*)&local , sizeof(local)) < 0 )    
  {    
    cerr << "bind error" << endl;    
    exit(2);    
  }    
                                                                                                                                                                                                                                                                                                                                                                    
  // listen     
  listen(listen_sockfd , 2);    
    
  for(;;)    
  {    
    ;    
  }    
  return 0;    
}

在运行./sever服务之后我们可以使用 netstat -nlpt命令来查看处于监听状态的进程

在这里插入图片描述
接下来使用Postman向我们的服务器发送一个请求

关于怎么使用Postman大家可以参考这个视频

如何使用Postman

在这里插入图片描述

说明： 需要说明的是我们这里之所以不选用浏览器（浏览器的就是基于TCP协议的）是因为浏览器如果没有收到服务端的响应可能会重复发送这个现象在我们介绍应用层的HTTP协议的时候有涉及

我们通过Postman发起请求之后可以使用下面的命令查看建立完毕的连接

netstat -npt | head -2 && netstat -npt | grep 8081

在这里插入图片描述

我们可以发现该连接现在处于ESTABLISHED状态接下来我们继续时候Postman发送第二三个请求

在这里插入图片描述

由于我们的服务器并没有调用accept函数获取已经建立好的连接所以说服务器已经建立好的连接是三个

我们继续尝试下使用Postman发送第四个请求

我们查看当前服务器的网络连接之后发现了这样子的现象

在这里插入图片描述
此时我们并没有增加ESTABLISHED状态了而是增加了一个SYN_RECV状态

而我们回看三次握手的场景

在这里插入图片描述

我们可以发现SYN_RECV状态出现在客户端给服务器发送建立连接请求但是服务器没有响应的时候

也就是说刚刚的Postman发送请求之后我们服务器并没有回应客户端的请求

过一段时间之后我们继续服务建立连接的状态

在这里插入图片描述
我们可以发现在一段时间过后三次握手失败该SYN_RECV连接就被自动释放了

而在Postman上表现为这样子

在这里插入图片描述

总结下上面的试验现象

不论有多少的客户端请求连接最终在我们的服务器端只会有三个连接建立成功
当发来第四个SYN请求的时候服务只是收到了却不做响应等待三次握手失败后自动释放连接

listen的第二个参数

我们直接对于上面的现象给出解释

实际上我们在进行TCP连接管理的时候会用到两个连接队列

全连接队列（accept队列）全连接队列用于保存处于ESTABLISHED状态但没有被上层调用accept取走的连接
半连接队列半连接队列用于保存处于SYN_SENT和SYN_RCVD状态的连接也就是还未完成三次握手的连接

我们在这里谈及Listen第二个参数的原因是在linux操作系统中全连接队列的长度就等于Listen的第二个参数+1 所以说我们服务器的Listen参数设置为2 此时服务器的全连接队列长度就为3 也就是说此时能够建立ESTABLISHED状态的连接就为3个

而当全连接队列满了之后服务器此时就不能够建立ESTABLISH连接了此时如果客户端请求建立连接那么服务器不会进行SYN+ACK响应而是会将该连接放在半连接队列中状态变为SYN_RECV 在一段事件后如果三次握手还没有成功则会自动释放连接

此外如果半连接队列也满了服务器会自动拒绝所有连接请求

如果被accept了全连接队列减少一个连接吗？

如果全连接中的队列被accept之后全连接队列会减少的

我们可以把服务器想象成一个饭店这个饭店可以提供128人吃饭（服务器可以接收的连接数默认是128）

但是这个饭店太火爆了几乎去的时候人都是满的（参考下海底捞）于是饭店老板便在饭店外面放了X+1个椅子（X为Listen的第二个参数）坐在饭店椅子上的人就可以认为他们正处于EXTABLISHED状态当饭店里面有人吃饭完饭店服务员就是使用accept函数让他们进来吃饭此时我们就可以认为全连接队列少了一个连接（此时在旁边站着的也就是半连接队列的人就可以坐上椅子变为EXTABLISHED状态）