一流高职院校建设计划项目网站,移动端网站建设的请示,购物网站建设方案ppt,WordPress调用外链文章目录前言一、再谈端口号端口号的划分认识知名端口号(Well-Know Port Number)两个问题nestatpidof二、UDP协议UDP协议端格式UDP的特点面向数据报UDP的缓冲区UDP使用注意事项基于UDP的应用层协议二、TCP协议TCP协议段格式可靠性问题确认应答(ACK)机制流量控制六个标志位PSHUG…
文章目录前言一、再谈端口号端口号的划分认识知名端口号(Well-Know Port Number)两个问题nestatpidof二、UDP协议UDP协议端格式UDP的特点面向数据报UDP的缓冲区UDP使用注意事项基于UDP的应用层协议二、TCP协议TCP协议段格式可靠性问题确认应答(ACK)机制流量控制六个标志位PSHUGERST超时重传机制连接管理验证ESTABLISHED状态CLOST_WAITTIME_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,也就是说首部长度至少为01016位标志位: 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
#includeiostream
#includestring
#includecassert
#includeunistd.h
#includesys/wait.h
#includesys/types.h
#includesys/stat.h
#includefcntl.h
#includesys/socket.h
#includestring.h
#includearpa/inet.h
#includefstream
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 的第二个参数,叫做底层的全连接队列的长度// 算法是:n1 表示在不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 $ $^ -stdc11
.PHONY:clean
clean:rm servermain.cc
#includeiostream
#includeserver.hppstatic void Usage()
{std::coutUsage: ./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,但是服务端不着急给客户端SYNACK,那么这是为什么呢?
引入listen接口的第二个参数! listen的第二个参数,叫做底层的全连接队列的长度.因为将来我们写的服务器可能会非常忙,没有办法处理非常多的请求,就需要讲这些请求排队!
全连接队列的长度是n1! 表示在不accpet的情况下,最多可以维护多少个链接!,上面我们传入的参数是2,也就是全连接队列的长度就是213!
为什么需要排队呢? 可以让我们的服务器在有闲置的情况下,里面从底层拿去连接,进行连接处理!为什么排队不能太长了呢? 用户发起请求后,一直在排队,影响了用户的体验.队伍太长,过于占用系统的资源,反而影响了服务器的效率.
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状态 我们使用Ctrlc终止了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_indexstart_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都是程序猿的工具,什么时机用,具体怎么使用,还是要根据具体的场景去判定的. 总结
(本章完!)
