当前位置：首页 > article >正文

传输层协议----UDP/TCP

article 2024/11/15 1:12:19

文章目录

前言
一、再谈端口号
- 端口号的划分
- 认识知名端口号(Well-Know Port Number)
- 两个问题
- nestat
- pidof
二、UDP协议
- UDP协议端格式
- UDP的特点
- 面向数据报
- UDP的缓冲区
- UDP使用注意事项
- 基于UDP的应用层协议
二、TCP协议
- TCP协议段格式
- - 可靠性问题
- 确认应答(ACK)机制
- 流量控制
- 六个标志位
- - PSH
  - UGE
  - RST
- 超时重传机制
- 连接管理
- - 验证ESTABLISHED状态
  - CLOST_WAIT
  - TIME_WAIT
  - 解决TIME_WIAT状态下bind error问题
- 滑动窗口
- 拥塞控制
- 延迟应答
- 捎带应答
- 面向字节流
- 粘包问题
- TCP异常情况
- TCP小结
三、TCP/UDP对比
总结

前言

传输层的作用就是负责数据能够从发送端传输到接收端.

正文开始!

一、再谈端口号

端口号(Port)标识了一个主机上进行通信的不同的应用程序;
在这里插入图片描述
在TCP/IP协议中中,用"源IP",“源端口号”,“目的IP”,“目的端口号”,"协议号"这样的一个五元组来标识一个通信(在Linux中可以通过netstat -n查看)

在这里插入图片描述

端口号的划分

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

认识知名端口号(Well-Know Port Number)

有些服务器是非常常用的,为了使用方便,人们约定一些常用的服务器,都是用以下这些固定的端口号:

ssh服务器,使用22端口
ftp服务器,使用21端口
telnet服务器,使用23端口
http服务器,使用80端口
https服务器,使用443端口

执行下面的命令,可以看到知名端口号

cat /etc/services

在这里插入图片描述
我们自己写一个程序使用端口号是,要避开这些知名端口号.

两个问题

一个进程是否可以bind多个端口号?
一个端口号是否可以被多个进程bind?
因为端口号是用来标定进程唯一性的,所以一个端口号只能bind一个进程,但是一个进程可以被多个端口号bind.

nestat

netstat是一个用来查看网络状态的重要工具.
语法:netstat[选项]
功能:查看网络状态
常用选项:

n 拒绝西安市别名,能显示数字的全部转化为数字
l 仅列出有在Listen(监听)的服务状态
p 显示建立相关链接的程序名
t (tcp)仅显示tcp相关选项
u (udp)仅显示udp相关选项
a (all)显示所有选项,默认不显示Listen相关

在这里插入图片描述

pidof

在查看服务器的进程id非常方便.
语法: pidof[进程名]
功能: 通过进程名,查看进程id.
在这里插入图片描述

二、UDP协议

UDP协议端格式

在这里插入图片描述

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

网络协议栈的tcp/ip协议,是内核中实现的,内核中使用C语言实现的.

struct udp_hdr
{
	unsigned int src_port;
	unsigned int dst_port;
	unsigned int udp_len;
	unsigned int udp_check;
};

以上就是udp报头类型,这就是位段.

UDP的特点

UDP传输的过程类似于寄信.

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

面向数据报

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

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

UDP的缓冲区

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

UDP的socket即能读,也能写,这个概念叫做全双工.

UDP使用注意事项

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

基于UDP的应用层协议

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

当然,也包括你自己写UDP程序时自定义的应用层协议;

二、TCP协议

TCP全程为"传输控制协议(Transmission Control Protocol").人如其名,要对数据的传输进行一个详细的控制;

TCP协议段格式

在这里插入图片描述

源/目的端口号:表示数据是从哪个进程来,到哪个进程去;
32位序号/32位确认号:后面详细来讲.
4位TCP报文长度:表示该TCP头部有多少个32位bit(有多少个4字节);所以TCP头部最大长度是15*4,也就是说首部长度至少为0101
6位标志位:
- URG:紧急指针是否有效
- ACK:确认号是否有效
- PSH:提示接收端应用程序立刻从TCP缓冲区把数据读走
- RST:对方要求重新建立连接;我们把携带RST标识的称为复位报文段
- SYN:请求建立连接;我们把携带SYN标识的称为同步报文段
- FIN:通知对方,本端要关闭了,我们把携带FIN标识的为结束报文段
16位窗口大小:后面详细讲.
16位校验和:发送端填充,CRC校验.接收端校验不通过,则认为数据有问题.此处的校验和不光包含TCP首部,也包含TCP数据部分.
16位紧急指针:标识那部分数据是紧急数据;
40字节头部选项:暂时忽略.

可靠性问题

1.什么是不可靠?

丢包,乱序,数据报校验失败…

2.怎么确认一个报文是丢了还是没丢??

我们发出去的消息,我们如何得知对方是否收到,只要得到应答就意味着我发给你的消息你一定收到了!

在长距离交互的时候,永远有一条最新的数据是没有应答的!

但是,只要发送的消息有对方的应答,我们就认为我们发送的消息,对方是收到的!

所以确认一个报文丢了还是没丢?,只要我们收到了应答,我们去人是没丢.否则:就是不确定!

建立一个共识:TCP在进行通信的时候,绝对不要忘记,发送出去的报文一定会携带tcp报头的!

确认应答(ACK)机制

TCP通过肯定的确认应答（ACK）实现可靠的数据传输。当发送端将数据发出之后会等待对端的确认应答。如果有确认应答，说明数据已经成功到达对端，反之，则数据可能丢失了。

在这里插入图片描述

报文中有个序列号字段，序列号是按顺序发送数据的每一个字节都编上号码的编号，接收端查询接受数据TCP首部中的序列号和数据的长度，将自己下一步应该接受的序号作为确认应答返回回去，就这样，通过序列号和确认应答号，TCP实现可靠传输
发送的数据.
在这里插入图片描述

序列号与确认应答号

在这里插入图片描述

当主机A发送数据（1-1000字节），如果主机B收到了这1000个字节，则确认序号为1001，发给主机A,当主机A收到发现确认应答是1001时，主机A就知道前1000字节主机B已经成功收到，就可以继续发送下面的数据了。每一个ACK都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据; 下一次你从哪里开始发.

那么为什么需要两组序号？为什么既有序号又有确认序号？

因为TCP是全双工的，我在给你发消息的同时，我也可以收消息。

流量控制

首先引入窗口大小的概念:客户端和服务端都有自己的发送缓冲区和接收缓冲区.这个缓冲区是有大小的,通常这个大小也是固定的.

如下图理解:
在这里插入图片描述

接收端处理数据的速度是有限的.如果发送端发的太快,导致接收端的缓冲区被打满,这个时候如果发送端继续发送,就会造成丢包,继而引起丢包重传等一系列的连锁反应.

因此TCP支持根据接收端的处理能力来决定发送端的发送速度.这个机制就叫做流量控制(Flow Control)

接收端将自己可以接收的缓冲区大小放入TCP首部中的"窗口大小"字段,通过ACK端通知发送端;
窗口大小字段越大,说明网络的吞吐量越高;
接收端一旦发现自己的缓冲区快满了,就会将窗口大小设置成为一个更小的值通知给发送端;
发送端接受到这个窗口之后,就会减慢自己的发送速度;
如果接收端缓冲区满了,就会将窗口置为0;这是发送方不在发送数据,但是需要定期发送一个窗口探测数据段,使接收端把窗口大小告诉给发送端.

在这里插入图片描述
接收端如何把窗口大小告诉发送端呢?回忆我们的TCP首部中,有一个16位窗口字段,就是存放了窗口大小信息;
那么问题来了,16位数字最大表示65535,那么TCP窗口最大就是65535字节吗?
实际上,TCP首部40字节选项中还包含一个窗口扩大因子M,实际窗口大小是窗口字段的值左移M位.

六个标志位

在这里插入图片描述

那么站在server的角度,客户端发来的请求有的是建立链接的,有的是进行正常通信的,有的是进行断开链接的.

所以报文也是有类别的!

SYN:只要报文是建立链接的请求,SYN需要被设置为1

FIN:只要报文是断开链接的请求,FIN需要被设置为1.

ACK:确认标记位,一旦被设置表示该报文是对历史报文的确认(不仅仅).我可以确认的同时,再给你发消息.

PSH

在这里插入图片描述
PSH:提示接收端应用程序立刻从TCP缓冲区把数据读走.

UGE

因为TCP协议中有32位序号,能保证数据按序到达对端,所以对端读取的时候也是按序读取,也就是说如果有一些数据优先级更高,但是序号比较晚,这样的报文需要对端立马读取该怎么办呢???---->所以URG标记位置为1就代表有紧急数据,需要立马读取.这时候16位紧急指针就代表紧急的数据在正文中的偏移量,方便对端去读取.

RST

因为TCP是面向连接的!

所以客户端和服务端就需要维护和管理这些连接而生成数据结构!

那么操作系统如何管理这些连接呢??—>先描述,在组织.

当然建立这些连接是需要花时间和花成本的.

那么为什么是三次握手呢?
在这里插入图片描述
所以此时三次握手就不一定能成功了!!!

那么一次握手可以吗?
就相当于客户端给服务端发送SYN后,双方就可以建立连接了.—>答案一定是不可以的,因为一次握手非常容易收到攻击.如果客户端一直给你发送SYN,因为是一次握手,客户端发送SYN,服务器就直接建立起来连接,然后服务器为了维护这个连接,就需要创建对应的数据结构.如果一直发送,就会导致服务器的资源大量的被消耗. 这种攻击就叫做SYN洪水攻击.
那么两次握手可以吗?
这次相当于客户端给服务端发送SYN,服务端给客户端发送ACK后,服务端就认为这次连接建立成功了,就需要维护对应的建立连接的数据结构.而客户端如果不接受或者直接丢弃这个ACK应答报文呢?
此时服务器的资源也就一直被消耗.
三次握手
一次握手和两次握手不行的根本原因在于都是让服务器先建立连接.而三次握手在客户端建立连接,而发起ACK被服务器收到的时候,服务器才会建立连接.
虽然也会建立连接,但是客户端也必须要建立连接,因为服务器的内存和资源一定远大于客户端,所以不害怕被客户端拉下水.
而三次握手这种奇数次握手,将最后一次报文成本嫁接给客户端.

最小成本验证TCP的IO功能(全双工)!!!

引入RST标志位

那么在三次握手中,客户端发送ACK之后服务端没有收到ACK,但是客户端自己不知道.所以客户端以为自己已经成功建立连接了,开始向服务端发起请求,但是服务端收到请求后,发现客户端没有发送ACK应答报文,服务端认为这次连接是有问题的,此时会将RST标志位置1,然后发送给客户端,告诉客户端之前可能建立连接失败了,需要重新建立连接.

超时重传机制

在这里插入图片描述

主机A发送数据给B之后,可能因为网络拥堵等原因,数据无法到达主机B;
如果主机A在一个特定时间间隔内没有收到B发来的确认应答,就会进行重发;

但是,主机A未收到主机B发来的确认应答,也可能是因为ACK丢了;

在这里插入图片描述
因此主机B会收到很多重复数据.那么TCP会收到很多重复数据.那么TCP协议需要能够识别出来那些包是重复的包,并且把重复的丢弃掉.这时候我们可以利用前面提到的序列号,就可以很容易做到去重的效果.

那么,如果超时,那么时间如何确定呢?

最理想的情况下,找到一个最小的时间,保证"确认应答一定能在这个时间内返回".
但是这个时间的长短,随着网络环境的不同是有差异的
如果超时时间设的太长,会影响整体的重传效率.
如果超时时间设置的太短,有可能会频繁发送重复的包

TCP为了保证无论在任何环境下都能有比较高性能的通信,因此回东台计算这个最大超时时间.

Linux中(BSD Unix和Windows也是如此),超时以500ms为一个单位进行控制,每次判定超时重发的超时时间都是500ms的整数倍.
如果重发一次以后,仍然得不到应答,等待2*500ms后在进行重传.
如果仍然得不到应答,等待4*500ms进行重传,以此类推,以指数形式进行递增.
累计到一定的重传次数,TCP认为网络或者对端主句出现异常,强制关闭连接.

连接管理

在正常情况下, TCP要经过三次握手建立连接, 四次挥手断开连接

在这里插入图片描述
服务端状态转化:

[CLOSED->LISTEN] : 服务器端调用listen后进入LISTEN状态,等待客户端连接.
[LISTEN->SYN_RCVD] :一旦监听到连接请求(同步报文段),就将该连接放入内核等待队列中,并向客户端发送SYN确认报文.
[SYN_RCVD -> ESTABLISHED] : 服务端一旦收到客户端的确认报文,进入ESTABLISHED状态,可以进行读写数据了.
[ESTABLISHED -> CLOSE_WAIT] : 当客户端主动关闭连接(调用close),服务器会收到结束报文段,服务器返回确认报文段并进入CLOSE_WAIT;
[CLOSE_WAIT -> LAST_ACK] : 进入CLOSE_WAIT后说明服务器准备关闭连接(需要处理完之前的数据);当服务器真正调用close关闭连接时,会向客户端发送FIN,此时服务器进入LAST_ACK状态,等待最后一个ACK到来(这个ACK是客户端确认收到了FIN)
[LAST_ACK ->CLOSED] : 服务器收到了对FIN的ACK,彻底关闭连接.

客户端状态转化

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

验证ESTABLISHED状态

server.hpp

#include<iostream>
#include<string>
#include<cassert>
#include<unistd.h>
#include<sys/wait.h>
#include<sys/types.h>
#include<sys/stat.h>
#include<fcntl.h>
#include<sys/socket.h>
#include<string.h>
#include<arpa/inet.h>
#include<fstream>
using namespace std;

class ServerTcp
{
public:
    ServerTcp(uint16_t port, string ip = "")
        : _listenSock(-1), _port(port), _ip(ip)
    {}
    ~ServerTcp()
    {
    }

public:
    void init()
    {
        // 1.创建socket
        _listenSock = socket(AF_INET, SOCK_STREAM, 0);
        if (_listenSock < 0)
        {
            exit(1);
        }

        int opt = 1;
        setsockopt(_listenSock,SOL_SOCKET,SO_REUSEADDR,&opt,sizeof(opt));
        //setsockopt(_listenSock,SOL_SOCKET,SO_REUSEPORT,&opt,sizeof(opt));

        // 2.bind绑定
        // 2.1填充服务器
        struct sockaddr_in local; // 用户栈
        memset(&local, 0, sizeof local);
        local.sin_family = AF_INET;
        local.sin_port = htons(_port);
        _ip.empty() ? (local.sin_addr.s_addr = INADDR_ANY) : (inet_aton(_ip.c_str(), &local.sin_addr));
        // 2.2本地socket信息，写入_sock对应的内核区域
        if (bind(_listenSock, (const sockaddr *)&local, sizeof local) < 0)
        {
            exit(2);
        }
        // 3.监听socket，为何要监听呢？tcp是面向连接的！
        // list 的第二个参数,叫做底层的全连接队列的长度
        // 算法是:n+1 表示在不accept的情况下 你最多能够维护多少个链接
        if (listen(_listenSock, 2 /*后面再说*/) < 0)
        {
            exit(3);
        }
        // 允许别人来连接你了
    }
    void loop()
    {
        while (true)
        {
            sleep(1);
        }
    }
private:
    int _listenSock;
    uint16_t _port;
    string _ip;
};

makefile

server:main.cc
	g++ -o $@ $^ -std=c++11
.PHONY:clean
clean:
	rm server

main.cc

#include<iostream>
#include"server.hpp"

static void Usage()
{
    std::cout<<"Usage: ./server port" << std::endl;
    exit(1);

}

int main(int argc,char* argv[])
{
    if(argc != 2) Usage();
    ServerTcp svr(atoi(argv[1]));

    svr.init();
    svr.loop();

    return 0;
}

在这里插入图片描述

这是zzy这台机器,域名是114.132.64.60.

在这里插入图片描述

这是hulu这台机器,域名是81.70.251.220.

在这里插入图片描述

在服务端我们进行listen监听后,不进行accept获取连接,客户端发起请求后就会处于ESTLABSHED状态哦!

现在我们建立多个连接,去连接服务端.看会有什么情况出现?

在这里插入图片描述

我们可以发现这里有三个连接建立成功,一个连接建立后处于SYN_RCVD状态,这就说明服务端收到了客户端的SYN,但是服务端不着急给客户端SYN+ACK,那么这是为什么呢?

引入listen接口的第二个参数!

在这里插入图片描述
listen的第二个参数,叫做底层的全连接队列的长度.因为将来我们写的服务器可能会非常忙,没有办法处理非常多的请求,就需要讲这些请求排队!

全连接队列的长度是n+1! 表示在不accpet的情况下,最多可以维护多少个链接!,上面我们传入的参数是2,也就是全连接队列的长度就是2+1=3!

为什么需要排队呢?
可以让我们的服务器在有闲置的情况下,里面从底层拿去连接,进行连接处理!
为什么排队不能太长了呢?
用户发起请求后,一直在排队,影响了用户的体验.队伍太长,过于占用系统的资源,反而影响了服务器的效率.

CLOST_WAIT

在这里插入图片描述
客户端主动退出以后,因为服务端没有掉close(fd)关闭文件描述符,此时服务端就会处于CLOSE_WAIT状态!结合我们四次挥手的流程图,我们可以认为四次挥手没有正确完成.

**小结:**对于服务器上出现大量的CLOSE_WAIT状态,原因就是服务器没有争取的关闭socket,导致四次挥手没有正确完成.这只是一个BUG,只需要加上对应的close就可以解决!

TIME_WAIT

如果我们服务端主动关闭连接的情况会发生什么呢?

看如下图:

在这里插入图片描述
主动断开连接的一方会进入TIME_WAIT状态!!!

此时我们再次监听8080号端口,但是显示我们bind error失败了!

在这里插入图片描述
这是因为虽然server的应用程序终止了,但是TCP协议层的连接并没有完全断开,因此不能再次监听同样的server端口.

TCP协议规定:主动关闭连接的一方要处于TIME_WAIT状态,等待2MSL的时间才能回到CLOSED状态
我们使用Ctrl+c终止了server,所以server是主动关闭连接的一方,在TIME_WAIT期间仍然不能再次监听同样的server端口
MSL在RFC1122中规定是2分钟.但是各个操作系统的实现不同,在Centos7上默认配置的值时60s.

为什么TIME_WAIT的时间是2MSL?

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

解决TIME_WIAT状态下bind error问题

在server的TCP连接没有完全断开之前不允许重新监听,某些情况下可能是不合理的.

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

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

在这里插入图片描述

此时就没有问题了!!!

滑动窗口

上面我们讨论了确认应答策略.对每一个发送的数据段,都要给一个ACK确认应答.收到ACK后再发送下一个数据段.这样做有一个比较大的缺点,就是性能比较差.尤其是数据往返的时间较长的时候.

在这里插入图片描述
既然这样一发一收的性能较低,那么我们一次发送多条数据,就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了).

在这里插入图片描述

窗口大小是指无需等待确认应答而可以继续发送数据的最大值.上图的窗口大小就是4000个字节(四个段).
发送前四个段的时候,不需要等待任何ACK,直接发送;
收到第一个ACK后,滑动窗户向后移动,继续发送第五个段的数据…以此类推;
操作系统内核为了维护这个滑动窗口,需要开辟 发送缓冲区 来记录当前还有那些数据没有应答;只有应答过的数据,才能从缓冲区删掉;
窗口越大,网络的吞吐率就越高;

在这里插入图片描述

如何理解缓冲区和滑动窗口
滑动窗口,一定会向右移动吗?
不一定向右运动,滑动窗口是可以变大的,也可以变小.因为这个滑动窗口的大小是由对方的接收能力决定的的!我收到的TCP数据报报头的窗口大小决定!

那么start_index和end_index是如何更新的呢?需要参考TCP报头的那些字段呢?

伪代码:start_index=确认序号,end_index=start_index+窗口大小字段.

那么如果数据出现了丢包,如何进行重传,这里分两种情况讨论
情况一:数据已经抵达,ACK被丢了

在这里插入图片描述
这种情况下, 部分ACK丢了并不要紧, 因为可以通过后续的ACK进行确认;

情况二:数据报直接就丢了.

在这里插入图片描述

当某一段报文段丢失之后,发送端会一直收到1001这样的ACK,就像是在提醒发送端"我想要的是1001"一样;
如果发送端主机连续三次收到了同样一个"1001"这样的应答,就会将对应的数据1001~2000重新发送;
这个时候接收端收到了1001之后,再次返回的ACK就是7001了(因为2001~7000)接收端其实之前就已经收到了,被放到了接收端操作系统内核的接收缓冲区中.

这种机制被称为"高速重发控制"(也叫"快重传").