文章目录
前言
传输层的作用就是负责数据能够从发送端传输到接收端.
正文开始!
一、再谈端口号
端口号(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)接收端其实之前就已经收到了,被放到了接收端操作系统内核的接收缓冲区中.
这种机制被称为"高速重发控制"(也叫"快重传").
拥塞控制
虽然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都是程序猿的工具,什么时机用,具体怎么使用,还是要根据具体的场景去判定的.
总结
(本章完!)