TCP
TCP概念
TCP全称为 “传输控制协议(Transmission Control Protocol”). 人如其名, 要对数据的传输进行一个详细的控制
- tcp是面向连接、可靠的流协议。流就是指不间断的数据结构，我们可以想象成是水管里的水。
- tcp为提供可靠性传输，实行了流量控制、拥塞控制等功能，下面会详细讲解。
TCP协议段格式
下图是TCP协议段格式：
- 源端口号和目的端口号：表示数据是从哪个进程来, 到哪个进程去
- 4位TCP报头长度: 表示该TCP头部有多少个32位bit(有多少个4字节); 所以TCP头部最大长度是15 * 4 = 60，4位首部长度，全0~全1，也就是0-15，首部以字节为单位，所以是60.那么减去20字节选项的大小就位40字节
- 6个标志位：
ACK: 确认号是否有效
PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走
RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段
FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段
URG: 紧急指针是否有效
如何将报头与有效载荷(数据)进行分离呢？
上层拿到以后，先读取20字节，再分析首部长度，如果首部长度有多少字节则继续读取，反之剩下的就是有效载荷。其它的下面会讲解，先来复习之前的3次握手和4次挥手
3次握手
tcp是面向连接的，所以要先建立连接：
建立连接的过程：
- 调用socket, 创建文件描述符;
- 调用connect, 向服务器发起连接请求;
- connect会发出SYN段并阻塞等待服务器应答; (第一次)
- 服务器收到客户端的SYN, 会应答一个SYN-ACK段表示"同意建立连接"; (第二次)
- 客户端收到SYN-ACK后会从connect()返回, 同时应答一个ACK段; (第三次)
4次挥手(断开连接)
断开连接的过程：
- 如果客户端没有更多的请求了, 就调用close()关闭连接, 客户端会向服务器发送FIN段(第一次)
- 此时服务器收到FIN后, 会回应一个ACK, 同时read会返回0 (第二次)
- read返回之后, 服务器就知道客户端关闭了连接, 也调用close关闭连接, 这个时候服务器会向客户端发送一个FIN;(第三次)
- 客户端收到FIN, 再返回一个ACK给服务器; (第四次)
为什么断开连接需要4次挥手？
因为是双方通信的，信道需要双方维护，举个例子：
这个例子有些不恰当，双方都通分手，那么我们就此是路人了。通信双方要都断开连接，这就是4次挥手。
TCP可靠性
绝对可靠和相对可靠
所以是没有绝对的可靠性的，但是能保证相对可靠。
所以可靠性是：只要收到对应的应答，那么之前的数据对方已经成功收到了。
RST
这就是RET的作用。
确认应答ACK
32位序号
序号是谁发谁填，接收方不用担心收到数据乱序的问题
确认序号
生活中2个人在对话时，1人说XXX，另1人说“我知道了”。那么说话的人知道对方听到了。我知道了就像是网络中的ACK确认应答。
主机A收到主机B的确认应答，主机A可以确定1-1000主机B收到了。
TCP将每个字节的数据都进行了编号. 即为序列号
每一个ACK都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据; 下一次你从哪里开始发.
面试题：为什么TCP要有序号，并且是2个序号？
因为TCP是全双工的，有可能双方在同时通信。序号保证收到数据的顺序问题，确认序号是确认应答，确认收到数据。
超时重传
数据报丢失情况1
- 主机A发送数据给B之后, 可能因为网络拥堵等原因, 数据无法到达主机B
- 如果主机A在一个特定时间间隔内没有收到B发来的确认应答, 就会进行重发
数据报丢失情况二：
- 主机B的ACK可能因为网络的问题在传送途中丢了，没有到达主机A
- 主机A会等待一段时间，若在特定的时间没有没有收到应答，主机A会对此数据进行重发，因为主机B收到过此数据，主机B可以通过序列号丢掉重复的数据。
所以序号还有去重的作用
下面简单看一下超时的时间如何确定：
- 最理想的情况下, 找到一个最小的时间, 保证 "确认应答一定能在这个时间内返回
- 但是这个时间的长短, 随着网络环境的不同, 是有差异的.
- 如果超时时间设的太长, 会影响整体的重传效率;
- 如果超时时间设的太短, 有可能会频繁发送重复的包;
TCP为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个最大超时时间
- Linux中超时以500ms为一个单位进行控制, 每次判定超时重发的超时时间都是500ms的整数倍.
- 如果重发一次之后, 仍然得不到应答, 等待 2*500ms 后再进行重传.
- 如果仍然得不到应答, 等待 4*500ms 进行重传. 依次类推, 以指数形式递增.
- 累计到一定的重传次数, TCP认为网络或者对端主机出现异常, 强制关闭连接
连接管理机制
详谈3次握手和4次挥手
3次握手:
客户端状态变化：
- [CLOSED -> SYN_SENT] 客户端调用connect, 发送同步报文段;
- [SYN_SENT -> ESTABLISHED] connect调用成功, 则进入ESTABLISHED状态, 开始读写数据;
服务器状态变化：
- [CLOSED -> LISTEN] 服务器端调用listen后进入LISTEN状态, 等待客户端连接;
- [LISTEN -> SYN_RCVD] 一旦监听到连接请求(同步报文段), 就将该连接放入内核等待队列中, 并向客户端发送SYN确认报文.
- [SYN_RCVD -> ESTABLISHED] 服务端一旦收到客户端的确认报文, 就进入ESTABLISHED状态, 可以进行读写数据了
为什么是3次握手呢？1次，2次，4次等不行吗？
**3次握手是用最小的成本来验证全双工**1次和2次都不行，都容易收到SYN洪水攻击，3次握手保证了客户端和服务器都发了一次和收了一次来确认双方都能通信。最后一次握手可能会失败，让服务器不要出现误判连接情况，减少服务器的资源浪费，服务器没收到ACK就不会建立- 4次、5次当然也可以，但是效率就变低了，建立连接是需要花费时间和空间的，肯定是要花费最小的成本
4次挥手
为什么4次挥手，因为断开连接是双方的。4次挥手重要的是客户端和服务器状态的变化：
客户端状态变化：
- [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 -> CLOSE_WAIT] 当客户端主动关闭连接(调用close), 服务器会收到结束报文段, 服务器返回确认报文段并进入CLOSE_WAIT;
- [CLOSE_WAIT -> LAST_ACK] 进入CLOSE_WAIT后说明服务器准备关闭连接(需要处理完之前的数据); 当服务器真正调用close关闭连接时, 会向客户端发送FIN, 此时服务器进入LAST_ACK状态, 等待最后一个ACK到来(这个ACK是客户端确认收到了FIN)
- [LAST_ACK -> CLOSED] 服务器收到了对FIN的ACK, 彻底关闭连接
理解TIME_WAIT
TIME_WAIT等待的意义：
1.尽量保证最后1个ACK被对方收到，进而尽快的释放服务器资源
2.等待历史数据在网络上消散，因为有些数据还在网络中，但是连接已经断开了。
CLOSE_WAIT
服务器没有关闭套接字的情况：
1 #include<iostream>
2 #include<sys/socket.h>
3 #include<sys/types.h>
4 #include<arpa/inet.h>
5 #include<netinet/in.h>
6 #include<unistd.h>
7 #include<signal.h>
8 #define BACKLOG 5
9 using namespace std;
10
11 class httpServer
12 {
13
14 private:
15 int port;
16 int lsock;
17 public:
18 httpServer(int _port=8080,int _lsock= -1)
19 :port(_port)
20 ,lsock(_lsock)
21 {}
22 void initServer()
23 {
24 signal(SIGCHLD,SIG_IGN);
25 lsock=socket(AF_INET,SOCK_STREAM,0);
26 if(lsock < 0)
27 {
28 cerr<<"socket error"<<endl;
29 exit(2);
30 }
31 struct sockaddr_in local;
32 local.sin_family = AF_INET;
33 local.sin_port = htons(port);
34 local.sin_addr.s_addr = INADDR_ANY;
35 int opt = 1;
36 setsockopt(lsock,SOL_SOCKET,SO_REUSEADDR,&opt,sizeof(opt));
37 if(bind(lsock,(struct sockaddr*)&local,sizeof(local)) < 0)
38 {
39 cerr<<"bind error"<<endl;
40 exit(3);
41 }
42 if(listen(lsock,BACKLOG) < 0)
43 {
44 cerr<<"listen error"<<endl;
45 exit(4);
46 }
47
48 }
49 void EchoHttp(int sock)
50 {
51 char response[2048];
52 ssize_t s = recv(sock,response,sizeof(response),0);
53 if(s > 0)
54 {
55 response[s] = 0;
56 string response = "HTTP/1.0 200 OK\r\n";
57 response += "Content-type: text/html\r\n";
58
59 response += "\r\n";
60
61 response += "<html><h1>hello </h1></html>";
62 send(sock,response.c_str(),response.size(),0);
63 }
while(1)
{
sleep(1);
}
64 // close(sock);
65 }
66 void start()
67 {
68 struct sockaddr_in peer;
69 for(;;){
70 socklen_t len = sizeof(peer);
71 int sock = accept(lsock,(struct sockaddr*)&peer,&len);
72 if(sock < 0)
73 {
74 cerr<<"accept error"<<endl;
75 continue;
76 }
77 if(fork() == 0)
78 {
79 close(lsock);
80 EchoHttp(sock);
81 exit(0);
82 }
83 close(sock);
84 }
85 }
86 ~httpServer()
87 {
88 if(lsock != -1)
89 {
90 close(lsock);
91 }
92 }
93 };
我们运行服务器并放在后台用抓包命令：
tcpdump -i any -nn tcp port 8080
这就是3次握手，然后关闭客户端，用命令查看：
服务器处于CLOSE_WAIT状态，如果有大量的客户端退出，服务器挂满了CLOSE_WAIT，会直接崩掉。我们再把服务器也关闭掉，它会释放没有关闭的连接资源：
服务器释放了连接资源。
所以服务器出现大量的CLOSE_WAIT就说明服务器没有关闭套接字
**让服务器先断开连接：**用命令：
netstat -ntp
查看连接：
先断开的连接的一方要进入TIME_WAIT，此时在启动服务器出现bind error的错误，如果此时有大量的链接来连接服务器，但是服务器的资源是有限的就会直接崩掉，所以我们要服用端口号。
int opt =1
setsockopt(listenfd,SOL_SOCKET,SO_REUSEADDR,&opt,sizeof(opt))
使用setsockopt()设置socket描述符的 选项SO_REUSEADDR为1, 表示允许创建端口号相同但IP地址不同的多个socket描述符,我们要使用这个函数来解决问题。加在初始化中：
22 void initServer()
23 {
24 signal(SIGCHLD,SIG_IGN);
25 lsock=socket(AF_INET,SOCK_STREAM,0);
26 if(lsock < 0)
27 {
28 cerr<<"socket error"<<endl;
29 exit(2);
30 }
31 struct sockaddr_in local;
32 local.sin_family = AF_INET;
33 local.sin_port = htons(port);
34 local.sin_addr.s_addr = INADDR_ANY;
35 int opt = 1;
36 setsockopt(lsock,SOL_SOCKET,SO_REUSEADDR,&opt,sizeof(opt));
37 if(bind(lsock,(struct sockaddr*)&local,sizeof(local)) < 0)
38 {
39 cerr<<"bind error"<<endl;
40 exit(3);
41 }
42 if(listen(lsock,BACKLOG) < 0)
43 {
44 cerr<<"listen error"<<endl;
45 exit(4);
46 }
47
48 }
此时服务器进入TIME_WAIT，不会再出现bind error，可以复用端口号了。
滑动窗口
刚才我们讨论了确认应答策略, 对每一个发送的数据段, 都要给一个ACK确认应答. 收到ACK后再发送下一个数据段.这样做有一个比较大的缺点, 就是性能较差. 尤其是数据往返的时间较长的时候.
既然这样一发一收的方式性能较低, 那么我们一次发送多条数据, 就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了)
确认应答不是以每个分段，发送端主机在发送一个以后不必要一直等待，是继续发送。
-
收到第一个ACK后, 滑动窗口向后移动, 继续发送第五个段的数据; 依次类推;
-
操作系统内核为了维护这个滑动窗口, 需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉
-
窗口越大, 则网络的吞吐率就越高
收到谁就可以把之前的过滤掉
第2 个收到，就往后滑，我们可以定义2个指针来指向窗口的左和右，往右滑2个指针++，但是不能一直往右，可能会越界，所以我们可以用环形队列来设计。滑动窗口在右移的途中可能会变大，变小，或者变为0。1个往缓冲区发数据，1个往缓冲区读数据，生产者消费者模型。
高速重发控制(快重传)
如果出现了丢包怎么办？
情况一：数据包已经递达，ACK丢了
这种情况下, 部分ACK丢了并不要紧, 因为可以通过后续的ACK进行确认;
情况二：数据包直接丢了
- 当某一段报文段丢失之后, 发送端会一直收到 1001 这样的ACK, 就像是在提醒发送端 “我想要的是 1001” 一样;
- 如果发送端主机连续三次收到了同样一个 “1001” 这样的应答, 就会将对应的数据 1001 - 2000 重新送;
- 这个时候接收端收到了 1001 之后, 再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了, 被放到了接收端操作系统内核的接收缓冲区中
有了快重传为什么还存在超时重传呢？
如果滑动窗口只能传3个数据，丢了2个不会触发快重传的机制。这2中重传机制并不会互相矛盾。
流量控制
接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送,就会造成丢包, 继而引起丢包重传等等一系列连锁反应.
因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控(FlowControl);
在TCP的报头中有自己的接收缓冲区的剩余的大小，我们可以知道对方能接收多大的数据了，就在16位的窗口大小中。
当接收端的缓冲区要面临数据溢出时，窗口大小会传到发送端。发送方等待接收方的通知再开始发送数据，但是发送方也不能等待时间过长，所以发送方会隔一会发送1个窗口进行探测(比如1秒钟)，如果接收方在0.3秒时能接收数据，还要等发送方来探测，这样还需要等0.7秒，就有点浪费时间了。所以接收方能接收数据了就会主动通知对方可以继续放送数据了`。
拥塞控制
TCP不仅要考虑双方还需要考虑网络的问题，如果在网络状况不好的时候，这是如果发送大量的数据就会导致网络状况更加糟糕。所以TCP引进了
慢启动 机制。
先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据。
- 此处引入一个概念程为拥塞窗口
- 发送开始的时候, 定义拥塞窗口大小为1;
- 每次收到一个ACK应答, 拥塞窗口加1;
- 每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较,
取较小的值作为实际发的窗口;
像上面这样的拥塞窗口增长速度, 是指数级别的. “慢启动” 只是指初使时慢, 但是增长速度非常快.
- 为了不增长的那么快, 因此不能使拥塞窗口单纯的加倍.
- 此处引入一个叫做慢启动的阈值
- 当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长
- 当TCP开始启动的时候, 慢启动阈值等于窗口最大值;
- 在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1;
小结一下：
少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为网络拥塞;
当TCP通信开始后, 网络吞吐量会逐渐上升; 随着网络发生拥堵, 吞吐量会立刻下降;
拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案.
延迟应答和捎带应答
如果接收数据的主机立刻返回ACK应答, 这时候返回的窗口可能比较小
- 假设接收端缓冲区为1M. 一次收到了500K的数据; 如果立刻应答, 返回的窗口就是500K;
- 但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了;
- 在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来;
- 如果接收端稍微等一会再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M;
窗口越大, 网络吞吐量就越大, 传输效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率;但肯定也不是所有的包都延迟应答，有数量限制和时间限制
- 数量限制: 每隔N个包就应答一次
- 时间限制: 超过最大延迟时间就应答一次
具体的数量和超时时间, 依操作系统不同也有差异; 一般N取2, 超时时间取200ms
捎带应答
在延迟应答的基础上, 我们发现, 很多情况下, 客户端服务器在应用层也是 “一发一收” 的. 意味着客户端给服务器说了 “How are you”, 服务器也会给客户端回一个 “Fine, thank you”; 那么这个时候ACK就可以搭顺风车, 和服务器回应的 “Fine, thank you” 一起回给客户端。
面向字节流
创建一个TCP的socket, 同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区
- 调用write时, 数据会先写入发送缓冲区中;
- 如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;
- 如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;
- 接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;
- 然后应用程序可以调用read从接收缓冲区拿数据;
- 另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做
全双工
由于缓冲区的存在, TCP程序的读和写不需要一一匹配
粘包问题
1.首先要明确, 粘包问题中的 “包” , 是指的应用层的数据包. 在TCP的协议头中, 没有如同UDP一样的 2.“报文长度” 这样的字段, 但是有一个序号这样的字段.
3.站在传输层的角度, TCP是一个一个报文过来的. 按照序号排好序放在缓冲区中.
4.站在应用层的角度, 看到的只是一串连续的字节数据.
5.那么应用程序看到了这么一连串的字节数据, 就不知道从哪个部分开始到哪个部分, 是一个完整的应用层数据包
那么如何避免粘包问题呢?明确两个包之间的边界
- 对于定长的包, 保证每次都按固定大小读取即可; 例如上面的Request结构, 是固定大小的, 那么就从缓冲区从头开始按sizeof(Request)依次读取即可;
- 对于变长的包, 可以在包头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置;
- 对于变长的包, 还可以在包和包之间使用明确的分隔符(应用层协议, 是程序猿自己来定的, 只要保证分隔符不和正文冲突即可
UDP是不存在黏包的，因为UDP有定长的报文长度
TCP异常情况
机器掉电/网线断开: 接收端认为连接还在, 一旦接收端有写入操作, 接收端发现连接已经不在了, 就会进行reset. 即使没有写入操作, TCP自己也内置了一个保活定时器, 会定期询问对方是否还在. 如果对方不在, 也会把连接释放.另外, 应用层的某些协议, 也有一些这样的检测机制. 例如HTTP长连接中, 也会定期检测对方的状态
小结
TCP保证了可靠性和提高了性能
可靠性
- 校验和
- 序列号(按序到达)
- 确认应答
- 超时重发
- 连接管理
- 流量控制
- 拥塞控制
提高性能
- 滑动窗口
- 快速重传
- 延迟应答
- 捎带应答
本篇文章到这就结束了。
998
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
