TCP协议
文章来自 shichang // Welcome!
主页
|
About Me
|
归档
|
标签
#### TCP协议的特点 1. 面向连接；2.点对点，端对端,提供端口与端口之间的通信；3.提供可靠服务：无丢失，无重复，无差错，无乱序；4.全双工通信；5.面向字节流 #### TCP的连接 端对端连接，端指的是套接字socket，一个套接字包括主机ip地址和主机进程端口号socket(ip,port) #### 可靠传输的工作原理 在不可靠的传输网络上提供可靠的传输的原理，确认机制，重传机制 #### 停止等待协议 客户端发送了分组后即停止发送，必须收到来自服务器的对这个分组的确认信息后才能继续发送 ##### 无差错，出现差错，确认丢失和确认迟到，信道利用率 无差错： client->server: 发送m1 server->client: 确认m1 <br> client->server的过程中，client没有收到确认的情况： 1. client发送的分组丢失——client超时重传 2. client发送的分组损坏被server丢弃——client超时重传 3. client发送的分组迟到——client超时重传 4. server发送的确认丢失——client超时重传——server丢弃重新收到的分组，发送确认 5. server发送的确认迟到——client超时重传——server丢弃重新收到的分组，发送确认 client在发出一个分组后，会保留发出的分组的副本，收到确认后才会删除副本，分组和确认分组都进行了编号一一对应，超时计时器的时间选择一般大于一次往返RTT 停止等待协议使得信道利用率和传输效率非常低，所以后面保留了确认机制，将发送方式改为滑动窗口提高了效率 #### ARQ自动重传请求协议，连续ARQ协议 Autometic Repeat reQuest,自动重传协议，超时即重传，连续ARQ协议，使用滑动窗口的形式控制分组的发送，在窗口内的分组可以全部发送，接收方一般采用累积确认的形式，在收到几个确认后，对按照顺序到达有序部分的最后一个分组发送确认，表示这个分组之前的分组都已经收到。但是这样也有不好的地方，例如发送方发送了21-50号数据，但是接受方接受到的数据为22，25，27。所以接受方返回的确认消息只会确认21，于是发送方又将21-50号数据全部重发，但其实有些数据已经到达了不需要重发 #### TCP报文段的首部格式 首部大小范围在20-60字节，其中选项保留40字节可选  1. 源端口和目的端口，各占两个字节，源端口号和目的端口号 2. 序号，给数据字节流中的每一个字节都编号，4个字节，共2^32位个序号，本报文段所发送数据的第一个字节的序号 3. 确认号，4字节，若确认号为N，则表明序号为N-1之前的所有数据都已经收到 4. 数据偏移，4bit，TCP首部的长度 5. 保留位6bit 6. URG紧急控制位，当URG为1时，说明有紧急数据要发送，紧急数据被插入到本报文数据的最前端，由紧急指针记录位置，后面仍然是普通数据（控制位只有0和1两种状态，无效和有效） 7. ACK确认控制位，ACK为1时，确认号字段才有效 8. PSH推送命令，将特定需传数据独立创建一个报文段直接发送尽快交付给应用进程，不管缓存 9. RST复位，有效时，表明TCP连接出现严重错误，需要断开连接再重新建立连接 10. SYN同步，建立连接时用来同步序号，SYN为1时表明这是一个连接请求或者连接接受报文 11. FIN终止，要求释放一个连接 12. 窗口，告知对方，我方允许对方发送多少数据量，即根据我方的数据缓冲空间大小，或是网络拥塞情况确定一个可以接受的数据量大小，可以使用窗口值进行流量控制和拥塞控制 13. 检验和，两字节，在TCP报文段首部加上12个伪首部后对整个报文段进行某种计算得出的检验和。接受方根据计算得出检验和如果不一致则丢弃说明传输有错 14. 紧急指针，两字节，表明紧急数据末端的位置，紧急数据的字节数。即使窗口为0也可以发送紧急数据 15. 选项，其他规定和设置，MSS最大数据字段长度(一般为536),窗口扩大，时间戳，选择确认等 #### 选项 窗口扩大：可以选择一个移位值S，原本窗口字段长度为16位，S的最大值为14，即可以将窗口扩大成30位，2^30 时间戳：可以用来计算往返时间RTT，加上时间戳可以防止序号绕回，序号不够用 #### 以字节为单位的滑动窗口 #### 超时重传时间的选择 karn算法：报文段每重传一次，就把超时重传时间RTO增大一些(2倍)，当不再发生报文段的重传时，采用如下公式计算: $ 新的RTTs = (1-a) * (旧的RTTs) + a * (新的RTT样本)$ $ RTO = RTTs + 4 * RTTd$ $ 新的RTTd = (1 - b) * (旧的RTTd) + b * |RTTs - 新的RTT样本|$ #### 选择确认SACK 累积确认原则，若收到的字节乱序，则重发时会经常重发已经正确接收到的数据，通过选择确认SACK选项，可以只让重发缺少的数据。具体做法是将已收到的数据碎片的起始两端分别用确认号记录下来发送给发送方，让发送方明确缺失的部分。但弊端是标记一个碎片快需要8个字节，选项只提供了40个字节的冗余，因此这种方法对于平常的多碎片情况也是无能为力 #### TCP的流量控制，利用滑动窗口来实现流量控制 让发送方的发送速率不要太快，让接受方能来得及接受。总之就是平衡发送方的发送速率和接收方的接收速率，让总体效率达到最优。利用可变的滑动窗口进行流量控制，接受方发送确认消息时附带发送给发送方接受窗口的数值，rwnd，表示允许发送方再发送多少数据。 问题：若接收方先发送了rwnd = 0，发送方接收到即不再发送。而接收方又发送了rwnd = 400，但是这个确认丢失了，如果没有措施，两方都将一直等待，形成死锁。 措施：TCP有一个持续计时器，当收到来自对方的*rwnd=0*时，即开始记时，时间到后若无消息则向对方发送试探消息，对方接收到试探消息后作出回应给出现在的窗口值，若为0则重新记时，若不为0则发送数据。 所以，为了避免这种情况应该规定：即使窗口值为零，也必须接受零窗口探测报文段，确认报文段和紧急报文段 #### 传输效率优化 控制TCP发送报文段的时机，Nagle算法，若发送应用进程把要发送的数据逐个写进TCP发送缓存，则发送方就把第一个字节先发送出去，把后面到达的数据字节都缓存起来，当发送方收到来自接收方的确认后，将缓存中所有的数据封装成一个报文段发送出去，同时对随后程序写入的数据写入缓存，收到前一个报文段的确认后，再发送下一个报文段。或者是，当确认过的数据已经达到发送窗口的一般以上时，立即发送一个报文段。这样做能有效提高网络的吞吐量 糊涂窗口综合症：由于发送方和接受方的生产消耗速率不匹配，导致两方的窗口值越来越小，最终每次传输带有少量字节的报文段，造成资源浪费。解决方法：分两种情况，若 #### TCP的拥塞控制 对网络中中转硬件资源的要求大于供给。供大于求。应防止过多的数据注入到网络中，使网络中的链路，路由器等过载。解决网络拥塞要从多个方面出发，考虑到中间件和客户端，服务器三方面的情况给出措施。 一般发送端进行了重发时，即可认为是可能出现了网络拥塞。随着数据注入量的提升，资源严重过载，网络吞吐量会增长得更慢进一步下降直到为0，形成死锁。 #### 慢开始，拥塞避免，快重传，快恢复 慢开始：在TCP刚开始传输数据时，使cwnd拥塞窗口(发送窗口)的大小设置为1个报文段，在每接收到一个ack之后将cwnd翻倍。同时，设置一个cwnd的门限值，当cwnd的大小超过门限值时，慢开始结束，更换为拥塞避免算法。 拥塞避免：当cwnd>sstresh时，再接收到ack时，cwnd不再翻倍，而是+1，缓步上升。当遇到一次重传时，认定为网络中出现了拥塞，需要降低cwnd的大小。 快恢复：一般是sstresh降低一半，cwnd=sstresh+3MSS.再收到ack时，将cwnd+1.门限值sstresh不得小于2。 快重传：一种重传方法，原始的重传是超时重传，快重传省去了超时等待，假设发送端发出了ABCDEF6个报文段，而接受方收到了ACDEF没有收到B，则，接收方发送了4次对B的确认，当对一个报文段的确认超过三次时，发送方即立即发送缺失的报文段。 #### 其他拥塞控制方法 TCP Vegas算法：这个算法通过对RTT的非常重的监控来计算一个基准RTT。然后通过这个基准RTT来估计当前的网络实际带宽，如果实际带宽比我们的期望的带宽要小或是要多的活，那么就开始线性地减少或增加cwnd的大小。如果这个计算出来的RTT大于了Timeout后，那么，不等ack超时就直接重传。（Vegas 的核心思想是用RTT的值来影响拥塞窗口，而不是通过丢包） High Speed TCP算法 TCP BIC算法 TCP WestWood算法 #### 随机早期丢弃Random Early Detection 针对网络中路由器资源的拥塞控制，在路由器队列中设置两个门限，当队列中的数量在第一门限内时，路由器工作正常。当队列中分组数量大于第一门限小于第二门限时，处于这部分的分组会被按照一定概率随机丢弃。当分组数量超过第二门限时，这部分的分组一定会被路由器丢弃。 #### TCP的运输连接管理 要使每一方都能确知对方的存在，要允许双方能够商议一些参数，要能够对运输实体资源进行分配。TCP采用客户服务器的方式建立连接  参考： [TCP那些事儿上](https://kb.cnblogs.com/page/209100/) [TCP那些事儿下](https://kb.cnblogs.com/page/209101/)
Pre:
注解@
Next: No Post
