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

---

前言

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

---

正文开始!

一、再谈端口号

端口号(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

我们自己写一个程序使用端口号是,要避开这些知名端口号.

两个问题

1. 一个进程是否可以bind多个端口号?
2. 一个端口号是否可以被多个进程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是面向连接的!

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

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

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

那么为什么是三次握手呢?

所以此时三次握手就不一定能成功了!!!

1. 那么一次握手可以吗?
   就相当于客户端给服务端发送SYN后,双方就可以建立连接了.—>答案一定是不可以的,因为一次握手非常容易收到攻击.如果客户端一直给你发送SYN,因为是一次握手,客户端发送SYN,服务器就直接建立起来连接,然后服务器为了维护这个连接,就需要创建对应的数据结构.如果一直发送,就会导致服务器的资源大量的被消耗. 这种攻击就叫做SYN洪水攻击.
2. 那么两次握手可以吗?
   这次相当于客户端给服务端发送SYN,服务端给客户端发送ACK后,服务端就认为这次连接建立成功了,就需要维护对应的建立连接的数据结构.而客户端如果不接受或者直接丢弃这个ACK应答报文呢?
   此时服务器的资源也就一直被消耗.
3. 三次握手
   一次握手和两次握手不行的根本原因在于都是让服务器先建立连接.而三次握手在客户端建立连接,而发起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.ccg++ -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!

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

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?

1. 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后,滑动窗户向后移动,继续发送第五个段的数据…以此类推;
• 操作系统内核为了维护这个滑动窗口,需要开辟 发送缓冲区 来记录当前还有那些数据没有应答;只有应答过的数据,才能从缓冲区删掉;
• 窗口越大,网络的吞吐率就越高;

1. 如何理解缓冲区和滑动窗口
   
2. 滑动窗口,一定会向右移动吗?
   不一定向右运动,滑动窗口是可以变大的,也可以变小.因为这个滑动窗口的大小是由对方的接收能力决定的的!我收到的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)接收端其实之前就已经收到了,被放到了接收端操作系统内核的接收缓冲区中.

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

拥塞控制

虽然TCP有了滑动窗口这个大杀器,能够高效可靠的发送大量的数据.但是如果在刚开始阶段就发送大量的数据,仍然可能引发问题.

是因为网络上有很多的计算机,可能当前的网络状态就已经比较拥堵.在不清楚当前网络状态下,贸然发送大量的数据,是很可能引起雪上加霜的.

那么如何确认网络出现问题了呢?—>大量丢包—>此时能不能重传呢?—>当然不能!!!

TCP引入慢启动机制,先发少量的数据,探探路,摸清当前的网络拥堵状态,再决定按照多大的速度传输数据;

• 此处引入一个概念拥塞窗口
• 发送开始的时候,定义拥塞窗口大小为1;
• 每次收到一个ACK应答,拥塞窗口+1;
• 每次发送数据包的时候,将拥塞窗口和接收端主机反馈的窗口大小做比较,取较小的值作为实际发送的窗口;

像上面这样的拥塞窗口增长速度,是指数级别的."慢启动"只是指初始时慢,但是增长速度非常快.

• 为了不增长的那么快,因此不能使拥塞窗口单纯的加倍
• 此处引入一个叫做慢启动的阈值
• 指数增长前期慢,意味着前期都可以发送少量的数据.指数增长前期慢+我们要尽快恢复网络通信的正常速度.指数增长后期快.
• 当拥塞窗口超过这个阈值的时候,不再按照指数方式增长,而是按照线性方式增长.

• 当TCP开始启动的时候,慢启动阈值等于窗口大小;
• 在每次超时重发的时候,慢启动阈值会变成原来的一般,同时拥塞窗口置回1;

少量的丢包,我们仅仅是触发超时重传;大量的丢包,我们就认为网络拥塞;

当TCP通信开始后,网络吞吐量会逐渐上升;随着网络发送拥堵,吞吐量会立刻下降;

拥塞控制归根结底是TCP协议想尽可能快的把数据传输给对方,但是又要避免给网络造成太大压力的这种方案.

延迟应答

如果接收数据的主机立刻返回ACK应答,这时候返回的窗口可能比较小.

• 假设接收端缓冲区为1M.一次收到了500K的数据;如果立刻应答,返回的窗口就是500K;
• 但实际上节能处理端处理的速度很快,10ms之内就把500K数据从缓冲区消费掉了;
• 在这种情况下,接收端处理还远没有达到自己的极限,即使窗口再放大一些,也能处理过来;
• 如果接收端稍微等一会再应答,比如等待100ms再应答,那么这个时候返回的窗口大小就是1M;

一定要记得,窗口越大,网络吞吐量就越大,传输效率就越高.我们的目标是在保证网络不用色的情况下尽量提高传输效率;

那么所以的包都可以延迟应答吗?肯定也不是;

• 数量限制:每隔N个包就应答一次;
• 时间限制:超过最大延迟时间就应答一次;

具体的数量和超时时间,不同的操作系统也有差异;一般N取2,超时时间取200ms;

捎带应答

在延迟应答的基础上,我们发现很多情况下,客户端服务器在应用层也是"一发一收"的.意味着客户端给服务器说了"How are you",服务器也会给客户端回一个"Fine,thank you";
那么这个时候ACK就可以搭顺风车,和服务器回应的"Fine,thank you"一起回给客户端.

面向字节流

创建一个TCP的socket,同时在内核创建一个发送缓冲区 和 接收缓冲区.

• 调用write时,数据会先写入发送缓冲区中;
• 如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;
• 如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;
• 接收数据的时候,数据也是从网卡驱动程序到达内核的接收缓冲区;
• 然后应用程序可以调用read从接收缓冲区拿数据;
• 另一方面,TCP的一个连接,既有发送缓冲区,也有接收缓冲区,那么对于这一个连接,就可以读数据,也可以写数据,这个概念叫做全双工.

由于缓冲区的存在,TCP程序的读和写不需要一一匹配,例如:

• 写100个字节数据时,可以调用一次write写100个字节,也可以调用100次write,每次写一个字节;
• 读100个字节数据时,也完全不需要考虑写的时候是怎么邪恶,既可以一次read100字节,也可以一次read一个字节,重复100次.

粘包问题

• 首先要明确,粘包问题中的"包",是指的应用层的数据包.
• 在TCP的协议头中,没有如同UDP一样的"报文长度"这样的字段,但是有一个序号这样的字段.
• 站在传输层的角度,TCP是一个一个报文过来的.按照序号排好序放在缓冲区中.
• 站在应用层的角度,看到的只是一串连续的字节数据.
• 那么应用程序看到了这么一连串的字节数据,就不知道从哪个部分开始到那个部分,是一个完整的应用层数据包.

那么如何避免粘包问题呢?—>明确报文和报文的边界!!!

• 对于定长的包,保证每次都按固定大小读取即可;例如上面的Request结构,是固定大小的,那么就从缓冲区从头开始按sizeof(Request)依次读取即可;
• 对于变长的包,可以在包头的位置,约定一个包总长度的字段,从而就知道了包结束的位置;
• 对于变长的包,还可以在包和包之间使用明确的分隔符(应用层协议,是程序猿来定的,只要保证分隔符不和正文冲突即可);

思考:对于UDP协议来说,是否也存在"粘包问题"呢?

• 对于UDP,如果还没有上层交付数据,UDP的报文长度依然存在.同时,UDP是一个一个把数据交付给应用层.就有很明确的数据边界.
• 站在应用层的站在应用层的角度,使用UDP的时候,要么收到完整的UDP报文,要么不收.不会收到"半个"的情况.

TCP异常情况

进程终止:进程终止会释放文件描述符,仍然可以发送FIN,和正常关闭没有什么区别.

机器重启:和进程终止的情况相同.

机器断电/网线断开:接收端认为连接还在,一旦接收端

TCP小结

为什么TCP这么复杂?因为要保证可靠性的同时又尽可能的提高性能.
可靠性:

• 校验和
• 序列号(按序到达)
• 确认应答
• 超时重传
• 连接管理
• 流量控制
• 拥塞控制
  提高性能:
• 滑动窗口
• 快速重传
• 延迟应答
• 捎带应答
  其他:
• 定时器(超时重传定时器,保活定时器,TIME_WAIT定时器等)

三、TCP/UDP对比

我们说了TCP是可靠连接,那么是不是TCP一定就优于UDP呢?TCP和UDP之间的优点和缺点,不能简单,绝对的进行比较

• TC用于可靠传输的情况,应用于文件传输,重要状态更新等场景;
• UDP用于对高速传输和实时性要求较高的通信领域,例如:早期的QQ,视频传输等.另外UDP可以用于广播;

归根结底,TCP和UDP都是程序猿的工具,什么时机用,具体怎么使用,还是要根据具体的场景去判定的.

---

总结

(本章完!)