Linux 网络基础---传输层

Posted 2022-04-17 qnbk

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Linux 网络基础---传输层相关的知识，希望对你有一定的参考价值。

传输层

传输层：负责数据能够从发送端传输到接收端
http等上层协议，本质不是把请求与响应发送给网络，而是将自己的数据给下层的协议(TCP)

端口号

在TCP/IP中，用"源ip",“源端口号”,“目的ip”,“目的端口号”，"协议号"来标识一个通信
//查看：

netstat -n

端口号划分

0~1023:知名端口号，HTTP,FTP,SSH等这些广为使用的应用层协议；它们的端口号都是固定的
1024~65535:操作系统动态分配的端口号，客户端程序的端口号，就是由操作系统从这个范围划分的

常见的端口号

SSH:服务器，使用22端口号
FTP:服务器，使用21端口号
telnet:服务器，使用23端口号
http:服务器，使用80端口号
https:服务器，使用443

查看知名端口号

cat /etc/services

less /etc/services

问题1：一个进程是否可以bind多个端口号？可以
问题2：一个端口号是否可以被多个进程bind？不可以

netstat

查看网络状态的工具

netstat [选项]

n 拒绝显示别名，能显示数字的全都转化成数字
l 仅列出又在listen(监听)的服务状态
p 显示建立相关链接的程序名
t (tcp)仅显示tcp相关选项
u (udp)仅显示udp相关选项
a (all)显示所有选项，默认不显示LISTEN相关

pidof

查看服务器的进程id

pidof [进程名]

UDP协议

udp协议端格式

16位UDP长度，表示整个数据报(UDP首部+UDP数据)的最大长度
如果校验和出错，就会直接丢弃

udp的特点

udp传输的过程类似于寄信

无连接：知道对端的ip和端口号就直接进行传输，不需要建立连接
不可靠：没有确认机制，没有重传机制；如果因为网络故障该端无法发到对方，upd协议也不会给应用层返回任何错误信息
面向数据报：不能够灵活的控制读写数据的次数和数量

面向数据报

应用层交给UDP多长的报文，UDP原样发送，既不会拆分，也不会合并
eg:用udp传输100个字节的数据

如果发送端调用一次sendo,发送100个字节，那么接收端也必须调用对应的一次recvfrom，接受100个字节，而不能循环调用10次recvfrom,每次接受10个字节

UDP的缓冲区

UDP没有真正意义上的发送缓冲区，调用sendo会直接交给内核，由内核将数据传给网络层协议进行后续的传输动作
UDP具有接受缓冲区，但是这个接受缓冲区不能保证收到的udp报的顺序和发送udp的顺序一致；如果缓冲区充满了，再到达的udp数据就会被丢弃

UDP的socket可读可写-》全双工

UDP的使用注意事项

UDP的协议首部有一个16位的最大长度，也就是说一个UDP能传输的数据最大长度是64K(包含UDP首部)。然而64K在当今的环境下是一个非常小的数字，如果需要传输的数据超过64K，就需要在应用层手动的分包，多次发送，并在接收端手动拼接

基于UDP的应用层协议

NFS:网络文件系统
TFTP:简单文件传输协议
DHCP:动态主机配置协议
BOOTP:启动协议(用于无盘设备启动)
DNS:域名解析协议
自定义协议

TCP协议

TCP：传输层控制协议，要对数据的传输进行一个详细的控制

TCP协议段格式

源/目的端口号：表示数据是从哪个进程来的，要到哪个进程去
4位TCP报头长度：表示该TCP头部有多少个32位bit(有多少个4字节)；所以TCP头部最大的长度是 15*4=60
6位标志位：tcp不同报文种类(不同的种类有不同的逻辑处理)
1. URG:紧急指针是否有效，紧急数据在报文中的偏移量
1. ACK:确认号是否有效
1. PSH:提示接收端应用程序立刻从TCP缓冲区把数据读走
1. RST:对方要求重新建立连接，我们把携带RST标识的成为复位报文段
1. SYN:请求建立连接；我们把携带SYN标识的成为同步报文段
1. FIN:通知对方，本端要关闭了，我们把携带FIN标识的称为结束报文段
16位校验和：发送端填充，CRC校验，接收端校验不通过，则认为数据有问题，此处的校验和不光包含TCP首部，也包含TCP数据部分
16位窗口大小：填充的是自身的接受缓冲区中剩余空间的大小；作用：支持流量控制
16位紧急指针：标识哪部分数据是紧急数据
40字节头部选项：暂时忽略
32位确认序号：通常代表收到的报文+1，代表告知对方A给B发送的N字节之前的所有字节B已经全部收到了，下次从N开始发送
TCP响应的也是完整的TCP报文

TCP保证可靠性：1、通过协议报头2、通过tcp代码逻辑体现

确认应答(ACK)机制

TCP将每个字节的数据都进行了编号，即为序列号

每一个ACK都带有对应的确认序列号，意思是告诉发送者，我已将收到了哪些数据，下一次就从哪里发

超时重传机制

序号功能：1、丢包超时重传2、去重
如何确定超时的时间？

最理想的状态下，找到一个最小的时间，保证“确认应答一定能在这个时间内返回”
时间的长短，随网络的环境不同而改变
超时的时间设置过长，会影响整体的重传效率
超时时间设置过短，有可能频繁的发送重复的包

TCP为了保证在任何环境下都能比较高性能的通信，因此会动态计算最大超时时间

Linux中，超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍
若重发一次后仍得不到应答，等待2500ms后再重传；若还得不到应答，等4500ms后重传，依此类推，以指数形式传递
累积到一定的重传次数，TCP认为网络或者对端的主机出现异常，强制关闭连接

连接管理机制

在正常情况下，TCP要经过3此握手建立连接，4此挥手断开连接
为什么是三次握手？
答：TCP是全双工协议，建立连接的核心是首先要验证双方通信信道是联通的，三次握手是双方通信信道的最小次数

谁最后发送ACK，谁就先维护连接
服务端状态转化

[CLOSE -> LISTEN]服务端调用listen后进入LISTEN状态，等待客户连接
[SYN_RCVD -> ESTABLISHED]服务端一旦收到客户端的确认报文，就进入ESTABLISHED状态，可以进行读写数据
[ESTABLISHED -> CLOSE_WAIT]当客户端主动关闭连接(调用close),服务器会收到结束报文，服务器返回确认报文并进入CLOSE_WAIT
[CLOSE_WAIT -> LAST_WAIT]进入CLOSE_WAIT后说明服务器准备关闭连接(需要处理完之前的数据)；当服务器调用close关闭连接时，会问客户端发送FIN,此时服务器进入LAST_ACK状态，等待ACK到来(次ACK是客户端确认收到了FIN)
[LAST_ACK_CLOSED]服务器收到了对FIN的ACK，彻底关闭连接

客户端状态转化

[CLOSE -> SYN_SENT]客户端调用connect,发送同步报文
[SYN_SENT ->ESTABLISHED]connect调用成功，进入ESTABLISHED状态，开始读写数据
[ESTABLISHED -> FIN_WAIT1]c客户端主动调用close时，向服务器发送结束报文段，同时进入FIN_WAIT1
[FIN_WAIT1 -> FIN_WAIT2]客户端收到服务器对结束报文的确认，进入FIN_WAIT2，开始等待服务器的结束报文段
[FIN_WAIT2 -> TIME_WAIT]客户端收到服务器发来的结束报文段，进入TIME_WAIT,并发出LAST_ACK；
[TIME_WAIT -> CLOSED]客户端要等待一个2MSL(报文最大生存时间)的时间，才会进入CLOSED状态

TIME_WAIT

TCP协议规定，主动关闭连接的一方要处于TIME_WAIT状态，等待2MSL个时间后才能回到CLOSED状态
使用ctrl+c终止server,所以server是主动关闭连接的一方，在TIME_WAIT期间仍然不能再次监听同样的server端口
MSL在Centos7上默认是60s
可以通过 cat/proc/sys/net/ipv4/tcp_fin_timeout查看MSL值

为什么TIME_WAIT时间是2MSL?

MSL是TCP报文最大的生存时间，因此TIME_WAIT持续存在2MSL的话就能保证在两个传输方向上的尚未被接受或迟到的报文段都已经消失(否则服务器立刻重启，可能会收到来自上一个进程迟到的数据，但是这种数据很可能是错误的)；
同时也是在理论上保证最后一个报文可靠到达(假设最后一个ACK丢失，那么服务器会再重发一个FIN,这时虽然客户的进程不在了，但是TCP连接还在，仍让可以重发LAST_ACK)

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

在server的TCP连接没有完全断开之前不允许重新监听

服务器需要处理非常大量的客户端数据的连接(每个连接的生存时间可能很短，但是每秒都有很大数量的客户端来请求)
如果服务器端主动关闭连接(eg:某个客户端啊不活跃，就要被服务器主动清理)，就会产生大量TIME_WAIT请求
由于请求量很大，就会导致TIME_WAIT的连接数很多，每个连接都会占用一个通信五元组(源ip,源端口，目的ip,端口协议)，其中服务器的ip和端口和协议是固定的，如果新来的客户连接的ip和端口号和TIME_WAIT占用的连接重复了，就会出现问题

#include <iostream>
#include <cstdlib>
#include <unistd.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <cstring>
#include <pthread.h>
const int port = 8081;
const int num = 5;
void* Routinue(void* arg)


  pthread_detach(pthread_self());
  int fd = *(int*)arg;
  delete (int*)arg;

  while(1)
  
    std::cout<<"thread run"<<pthread_self()<<std::endl;
    sleep(1);
  
  return nullptr;

int main()


  int lsock = socket(AF_INET,SOCK_STREAM,0);
  if(lsock < 0)
  
    std:: cerr<<"socket error"<<std::endl;
    return 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(lsock,(struct sockaddr*)&local,sizeof(local)) < 0)
  
    std::cerr<<"bind error"<<std::endl;
    return 2;
  
  if(listen(lsock,num) < 0)
  
    std::cerr<<"listen error"<<std::endl;
    return 3;
  
  struct sockaddr_in peer;
  for(;;)
  
    socklen_t len = sizeof(peer);
    int sock = accept(lsock,(struct sockaddr*)&peer,&len);
    if(sock < 0)
    
      std::cerr<<"accept error"<<std::endl;
      continue;
    
    //获取连接
  std::cout << "get a new link"<<sock <<std::endl;
    int *p = new int(sock);
    pthread_t tid;
    pthread_create(&tid,nullptr,Routinue,p);
  
  return 0;

使用setsockopt()设置socket描述符的选项SO_REUSEADDR为1，表示允许创建端口号相同但ip地址不同的多个socket描述符

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

理解CLOSE_WAIT状态

服务器出现CLOSE_WAIT状态，原因就是服务器没有正确的关闭socket,导致4次挥手没有正确完成，只需要加上close即可解决问题

滑动窗口

确认应答策略：对每一个发送的数据段，都要给一个ACK确认应答，收到ACK后再发送下一个数据段，这样有缺点：性能差
-》既然一发一送的性能较低，那么一次发多条数据，可以大大的提高性能(其实是将多个段的等待时间重叠到一起了)

滑动窗口：在自己的发送缓冲区中，限定的一块区域可以直接发送，暂时不用ACK

窗口大小指的是无需等待确认应答机制而可以继续发送数据的最大值(对方的接受能力，衡量的是对方缓冲区剩余空间的大小)
发送前4个段的时候，不需要等待任何的ACK，直接发送
收到第一个ACK后，滑动窗口向后移动，继续发送第5个段的数据，以此类推
操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有应答，只有确认应答过的数据，才能从缓冲区删掉
窗口越大，网络的吞吐率越高

如果出现丢包，如何进行重传？

当某一段报文丢失之后，发送端会一直收到1001这样的ACK，如果发送端主机连续三次收到了同一个ACK，就会将对应的数据重新发送
接收端收到了1001之后，再次返回的ACK就是4001了因为2001~4000，接收端已经收到了，被放到操作系统内核的接受缓冲区中
这种机制也叫“高速重发机制”(快重传)

流量控制

接收端处理数据的速度是有限的，如果发送端发的太快，这个时候如果发送端继续发送就会造成丢包，继而引起丢包重传等一系列连锁反应
因此TCP支持根据接收端的处理能力，来决定发送端的发送速度，这个机制叫做流量控制

接收端将自己可以接收的缓冲区大小放入TCP首部中的“窗口大小”字段，通过ACK端通知发送端
窗口大小的字段越大，说明网络的吞吐量越高
接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端，发送端接收端到这个窗口之后，就会减慢发送速度
如果接收端缓冲区满了，就会将窗口设置为0；此时发送方不再发送数据，但是需要定期发送一个端口探测数据段，使接收端把窗口大小告诉发送端
在TCP首部，有一个16位窗口字段，就是存放了窗口大小信息，TCP首部40字节还包含了一个窗口扩大因子M，实际窗口大小是窗口字段的值左移M位

拥塞控制

虽然TCP滑动窗口能传输大量的数据，但是如果在刚开始的阶段就发送大量的数据，仍然能引发问题。

TCP引入慢启动机制，先发送少量的数据，摸清当前网络拥塞状态，再决定按照多大的速度传输数据
拥塞窗口：

发送开始的时候，定义拥塞窗口大小为1
每次收到一个ACK应答，拥塞窗口+1
每次发送数据包的时候，将拥塞窗口和接收端主机反馈的窗口大小作比较，取较小值作为实际发送的窗口
像这样的拥塞窗口增长速度，是指数级别的“慢启动”只是初始时满，但是增长速度快
为了增长的不那么快，因此不能时拥塞窗口单纯的加倍
慢启动阈值：当拥塞窗口超过阈值时，不再按照指数方式增长，而是按照线性方式增长
每当tcp开始启动时，慢启动阈值等于窗口最大值
每次超时重发时，慢阈值会变成原来的一半，同时拥塞窗口置回1