赞
踩
udp协议报头数据表格
16位源端口号 | 16位目的端口号 | 16位UDP长度 | 16位UDP校验和 | 数据 |
---|---|---|---|---|
2字节 | 2字节 | 2字节 | 2字节 | 最大2^16 - 1字节的数据 |
TCP报头表格
16位源端口号 | 16位目的端口号 | 32位序列号 | 32位确认号 | 4位首部长度 | 6位标志位 | 16位窗口大小 | 16位校验和 | 16位紧急指针 | 数据 |
---|---|---|---|---|---|---|---|---|---|
2字节 | 2字节 | 4字节 | 4字节 | 4位 | 6位 | 2字节 | 2字节 | 2字节 | 最大2^16 - 1字节的数据 |
序列号: TCP对其数据帧中每一个字节的数据都做了一个编号,发送方用这些序号标记哪些数据发送出去。
确认序号: 接收方响应给发送方时,用确认序号告诉发送方,接收方寂静收到了确认序号之前的那些数据,这个确认序号就告诉发送方,下一个数据应该从哪个序号开始发送。
ACK: 确认序号标志位,当ACK=1时,确认序号有效,当ACK=0时,确认序号无效。
值得注意的是,确认应答要保证前面的数据发过去了,也就是收到了ACK,才会继续发下一次的数据。
问,为什么不只用一个序号就够了吗?为何还需要确认序号呢?
答:因为TCP的链接实际不分客户端服务端,建立了链接之后就是双向平等的,别忘了,上面Server短发回去的也是一个完整的TCP报文,那这个报文的是不是也有自己的数据呢,那么这份数据也是需要序号的,否则单独拿一个TCP报文来应答不是很低效吗。
网络发送中,丢包显然是常见的事,那么对UDP而言,其不可靠性决定了丢包了UDP是不管的。而TCP保证可靠性,所以如果对于主机A发送的数据没有收到应答,那么A不会直接发送后续的数据,而是等着应答,但是不可能一直等待吧,万一B主机根本没有收到呢?所以就需要超时重传。这一个不受到之前发送数据的应答,就不发送之后的数据,这一特点既有好处又有坏处。
问:超时重传的时间应该如何确定?
建立连接:TCP三次握手
过程描述:
首先主机A向主机B发送连接请求SYN(同时携带有数据,所以自然也有序号seq,序号的事不再提及)此时主机B收到,这是第一次握手;
后向主机B发送响应ACK,同时也发送SYN请求A主机连接。当A主机收到,B的信息,这是第二次握手,此时A主机就认为连接已经建立好。
A主机建立好连接,并且发出响应给B主机,此时B主机收到ACK后,开始建立与A主机的连接。这是第三次握手。
许多教材或者网上甚至是AI都有对三次连接的生动形象的描述,此篇不多提及,来看看几个问题来帮助理解三次握手。
问:为什么建立连接需要三次握手,一次,两次,或者四次吗?
答:一次握手不行,为什么?因为如果一次连接就可以,那么势必导致服务器端也就是上述的主机B在接受连接时,处于一种容易被平白无故消耗资源的地位,只要由单个连接来,就建立,这显然效率十分低下,再者倘若如此,和UDP的无连接差距并不明显。
两次握手不行吗?不行,原因也很简单,一样的是对服务器端不公平,只要A主机发来请求,B主机就要建立连接,那么这容易造成资源浪费。你可能会说在第二次握手时客户端A就建立了连接,那不是对客户端不公平?但是时客户端发起的连接请求,所以客户端先建立连接是合理的。
那么四次呢?答案是可以的,但是没有必要,实际上理解三次握手就可以看作四次握手来理解。分别是A->B 的SYN,B->A 的ACK, B->A的 SYN ,A->B的ACK。那为什么是三次呢?原因是B给A的ACK和SYN一次就发送了。所以就是我们看到的三次握手了。
问:为什么要有这种握手SYN_ACK机制?
答:因为网络之中,无论怎么发送,AB主机通信,总是不能保证最新的那条消息对方收到了没。就如同QQ发消息一样(有些邮件类会显示对方已读,也就是对方未显示已读),对方没给你会消息,你就永远不知道对方看见你的上一条消息没,序号正好用来解决这个问题。同时这也是为什么建立连接时需要三次握手,我总要保证对方在线吧。
断开连接:TCP四次挥手
理解了上面的三次握手骂我们来看四次挥手:
过程描述:
主机A想主机B发送FIN的信号,告诉主机B要断开连接,B收到A的FIN信号,第一次次挥手;
这个时候主机B并没有类似与之前的三次握手那样就直接发送ACK和FIN信号,而是先回应客户端ACK信号之后,然后让A主机收到,这是第二次挥手;
接着过了CLOSE_WAIT过后呢,这个时候主机B再向主机A发送FIN信号,告诉主机B断开连接。这是第三次挥手;
接着主机A发送给主机B响应之后,主机B收到就断开连接。但是主机A需要等待TIME_WAIT时间(一般是2*MSL)
一样来解答几个关键问题。
问:如果你理解了我提出的三次握手,那么为什么是四次挥手也无需多言,思考以下为什么会呈现为四次挥手?因为CLOSE_WAIT需要等待一段时间。
为什么需要CLOSE_WAIT和TIME_WAIT这这两个等待时间呢?为什么不能直接和建立连接那样呢?
答:
TIME_WAIT的存在意义,1.TCP里面,规定TIME_WAIT是2个MSL(maximum segment lifetime),这个MSL指的是TCP报文最大生存时间,只要等待2MSL,2.就能保证传输或者发送的报文都在网络中消散干净,3.等待这么久,同时也使得对被动关闭方主机的ACK是否收到,如果没收到被动方也就是主机B可以再发一个FIN这样即使主机A的进程没了,但是连接还在久依旧能处理。试想以下如果没有这个,那么当服务器主动关闭后,就有可能再次收到之前进程的报文(而该报文大概率是错误的)。这里还值得一说的是,TCP的序号每次开始三次握手时会确定一个随机起始序号,也能一定程度上防止这种问题。
CLSOE_WAIT是用来干什么的呢?一般是表示有些数据呢,被动端还没有处理完毕,这个时候就会进行CLOSE_WAIT,一般来说CLOSE_WAIT状态时很短暂的。如果出现CLOSE_WAIT,大概率时没有正确关闭套接字,比如Svr没有去调用close久退出了进程。
TCP常常说滑动窗口,那么什么是滑动窗口呢?用程序员比较熟悉的话说,就是在一段连续的数组空间就是滑动窗口,这个数据单个大小元素就是字节,而所谓的滑动窗口就是这段数组的部分区间。
由上述印象之后,我们来看几个问题。
为什么要搞滑动窗口?
因为TCP是确认应答机制,发一个字节需要确认之后再发送,不会显得效率很低吗?尤其是网络状况差时。TCP是要兼顾一定效率的。
通过发送滑动窗口区间的数据,就不需要确认应答,直接发送就行。收到最后部分数据,如上图的第9的那一部分发送后,接着发送下一部分。如果说中间有发送失败的,重发即可。
上述问题之后,我们考虑滑动窗口大小如何确定?滑动窗口发过去的数据如何确定顺序呢?如果确定发完了呢?
如何确定大小?三次握手的时候,彼此不都又SYN和ACK吗,这就是用 16位窗口大小 来确定彼此的滑动窗口的大小。如何确定顺序和这个窗口是否发完?毫无疑问就是序号,通过需要了确定这部分数据的顺序即可,这样就在接受缓冲区确定了数据顺序。最后一份数据的ACK就可以表示。
如过丢包了呢?数据包丢了如何,ACK响应丢了又如何?
如果是ACK丢包了,不影响,因为最后一份确认序号的ACK能表示之前的都收到了。如果是数据包呢?那么发送丢失的数据包的序列号请求即可,比如上述图的5号丢失,那么接收方只需要发送5的序号请求即可。
对于TCP,我们知道是全双工的,同时也有一个滑动窗口,那么如果发送方嘎嘎发,导致接收方缓冲区满了怎么办?这种时候就需要流量控制。
接收端如何把窗口大小告诉发送端呢? 回忆我们的TCP首部中, 有一个16位窗口字段, 就是存放了窗口大小信息;
那么问题来了, 16位数字最大表示65535, 那么TCP窗口最大就是65535字节么?
实际上, TCP首部40字节选项中还包含了一个窗口扩大因子M, 实际窗口大小是 窗口字段的值左移 M 位
虽然有了滑动窗口,但是依然不足以应对复杂的网络环境。倘若网上有大量主机在使用网络,而你又在嘎嘎发数据,网络情况不是变得更差?
因此就有了慢启动,快增长,快速重传
TCP引入 慢启动 机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据
此处引入一个概念程为拥塞窗口
发送开始的时候, 定义拥塞窗口大小为1;
每次收到一个ACK应答, 拥塞窗口加1;
每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗
口
少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为网络拥塞;
当TCP通信开始后, 网络吞吐量会逐渐上升; 随着网络发生拥堵, 吞吐量会立刻下降;
拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案
如果接收数据的主机立刻返回ACK应答, 这时候返回的窗口可能比较小.
假设接收端缓冲区为1M. 一次收到了500K的数据; 如果立刻应答, 返回的窗口就是500K; 但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了;在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来;如果接收端稍微等一会再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M;一定要记得, 窗口越大, 网络吞吐量就越大, 传输效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率;
那么所有的包都可以延迟应答么?
肯定也不是
数量限制: 每隔N个包就应答一次;
时间限制: 超过最大延迟时间就应答一次;
具体的数量和超时时间, 依操作系统不同也有差异; 一般N取2, 超时时间取200ms;
捎带应答:每一份TCP报文既有确认序号,又有序号,也就是说既有收到的信息,也有发给对端的信息,这就是捎带应答,例如三次握手的第二次
面向字节流
创建一个TCP的socket, 同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区;调用write时, 数据会先写入发送缓冲区中;
如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;
如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出
去;
接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;
然后应用程序可以调用read从接收缓冲区拿数据;
另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做 全双工
由于缓冲区的存在, TCP程序的读和写不需要一一匹配, 例如:
写100个字节数据时, 可以调用一次write写100个字节, 也可以调用100次write, 每次写一个字节;
读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100个字节, 也可以一次
read一个字节, 重复100次;
TCP是面向字节流的,怎么分清楚数据与数据之间呢?
答案是明确两份数据之间的边界,例如基于此的http1.0,http1.1,http2.0等的应用层协议
进程终止/机器重启:也就是正常关闭,正常走流程
机器突然掉电/网线断开:那么接受端认为连接还在,一旦进行写操作就会发现,此时进行reset,也就是询问这个连接是否还在,需要重新建立或者断开
可靠性:
TCP不见得就比UDP好,很显然TCP为了可靠是付出了许多代价的。因此要根据场景来选择
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。