目录

●TCP段格式

●TCP定时器

●TCP三次握手和四次挥手


●TCP段格式

6位标志位有紧急标志URG推送标志PSH确认标志ACK复位标志RST链接同步标志SYN以及结束标志FIN

○紧急标志URG(U):

占1位,当URG=1时,表示紧急指针字段有效。通知发送方本数据报文段中含有紧急数据,需要马上传输,这时发送方不会等到缓冲区满再发送,而是直接优先将该报文段发送出去。

○推送标志PSH(P):

占1位,PSH=1时,表示当前报文段需要请求推送(Push)操作,即接收方TCP收到推送标志位为1的报文时 ,就立即提交给接收的应用进程,而不必等到整个缓存都填满后再向上提交。

○URG和PSH的区别:

① 紧急URG将紧急报文字段插入到普通报文字段的前面,而推送PSH是利用紧急数据重新直接创建一个报文,并立即发送出去; 
       ② URG=1,表示紧急数据(数据从序号开始到紧急指针指向字节)不经过缓冲区直接交付应用进程,PSH=1表示尽快推送,将数据先交给缓冲区,不等待缓冲区填满(默认TCP/IP是将数据缓存到一定上限,才交由上层)就交给上层程序; 
       ③ URG=1交给上层进程的只有紧急数据,PSH=1交给上层程序的是紧急数据和之前接收方缓冲区排好序的数据。

●TCP定时器

对于每个连接,TCP 管理着四个不同的定时器:重传定时器、坚持定时器、保活定时器 以及 2MSL 定时器:

○重传定时器

为了防止丢失数据报文段或确认报文段,当 TCP 发送报文段时,启动了特定报文段的重传计时器,若在计时器超时之前收到对报文段的确认,则撤销计时器。若收到特定报文段的确认之前计时器已经超时,则重传该报文,并把计时器复位。这里最重要的是超时的时间计算,有关该时间的请查阅具体的算法,这里不再进行记录。

○坚持定时器

坚持定时器主要是解决零窗口大小通知可能导致的死锁问题。刚开始接收端向发送端发送了一个零窗口报文段。在不久之后,如果接收端的缓存区有一定的空间可以接收数据,此时接收端就会向发送端发送了一个非零窗口大小的报文段(即窗口更新),但是这个非零窗口大小的报文段在传输过程中丢失,导致发送端无法接收到该非零窗口大小的报文段。因此,发送端就会一直处于等待非零窗口大小的报文端通知,由于接收端已经发送了非零窗口大小的报文段,而且并不知道该报文段在传输过程中丢失,则接收端会一直处于等待接收数据状态,如果没有任何措施的话,这个死锁的局面会一直延续下去。

为了解决上面这个问题,TCP 为每一个连接设有一个坚持定时器(也叫持续计数器)。当发送端收到零窗口的确认时,就启动坚持计时器,当坚持计时器截止期到时,发送端就发送一个特殊的报文段,叫探测报文段,这个报文段只有一个字节的数据。探测报文段有序号,但序号永远不需要确认,甚至在计算对其他部分数据的确认时这个序号也被忽略。探测报文段提醒接收端,确认已丢失,必须重传。

坚持计时器的截止期设置为重传时间的值,但若没有收到来自接收端的响应,则发送另一个探测报文段,并将坚持计时器的值加倍和并复位,发送端继续发送探测报文段,将坚持计时器的值加倍和复位,直到这个值增大到阈值为止(通常为 60 秒)。在此之后,发送端每隔 60s 就发送一个报文段,直到窗口重新打开为止。

坚持定时器的原理:当 TCP 服务器收到了客户端的 0 滑动窗口报文时,启动一个定时器来计时,并在定时器溢出的时向客户端查询窗口是否已经增大,如果得到非零的窗口就重新开始发送数据,如果得到零窗口就再开一个新的定时器准备下一次查询。

○保活定时器

保活定时器是为了应对 TCP 连接双方出现长时间的没有数据传输的情况。如果客户端与服务器建立了 TCP 连接之后,客户端由于某种原因导致主机故障,则服务器就不能收到来自客户端的数据,而服务器不可能一直处于等待状态,保活定时器就是用来解决这个问题的。服务器每收到一次客户端的数据,就重新设置保活定时器,通常为 2 小时,如果 2 小时没有收到客户端的数据,服务端就发送一个探测报文,以后每隔75秒发送一次,如果连续发送10次探测报文段后仍没有收到客户端的响应,服务器就认为客户端出现了故障,就可以终止这个连接。

○2MSL 定时器

2MSL 定时器主要是解决以下两种情况:

TIME_WAIT 确保有足够的时间让对端收到了ACK,如果被动关闭的那方没有收到 ACK,就会触发被动端重发 FIN。因为最后一次确认应答 ACK 报文段很有可能丢失,因而使被动关闭方处于在LIST_ACK 状态的,此时被动关闭方会重发这个 FIN+ACK 报文段,在这等待的 2MSL 时间内主动关闭方重新收到这个被动关闭方重发的 FIN+ACK 报文段,因此,主动关闭方会重新发送确认应答信息,从而重新启动 2MSL 计时器,直到通信双方都进入 CLOSED 状态。如果主动关闭方在 TIME_WAIT 状态不等待一段时间就直接释放连接并进入 CLOSED 状态,那么主动关闭方无法收到来自被动关闭方重发的 FIN+ACK 报文段,也就不会再发送一次确认 ACK 报文段,因此被动关闭方就无法正常进入CLOSED 状态。

有足够的时间让这个连接不会跟后面的连接混在一起。防止已失效的请求连接出现在本连接中。在连接处于 2MSL 等待时,任何迟到的报文段将被丢弃,因为处于 2MSL等待的、由该插口(插口是IP和端口对的意思,socket)定义的连接在这段时间内将不能被再用,这样就可以使下一个新的连接中不会出现这种旧的连接之前延迟的报文段。

●TCP三次握手和四次挥手

○1~3是建立连接的过程,也叫“三次握手”,进行“三次”握手的原因是:

“已失效的连接请求报文段”的产生在这样一种情况下:client发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后,就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段,同意建立连接。假设不采用“三次握手”,那么只要server发出确认,新的连接就建立了。由于现在client并没有发出建立连接的请求,因此不会理睬server的确认,也不会向server发送数据。但server却以为新的运输连接已经建立,并一直等待client发来数据。这样,server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。

○7~10是断开连接的过程,也叫“四次挥手”,“四次”挥手的原因是:

四次挥手是因为TCP为全双工模式,接收到FIN时意味将没有数据再发来,但是还是可以继续发送数据。

首先调用close()发起主动关闭的一方会进入TIME_WAIT状态。进入TIME_WAIT状态的TCP连接需要经过2MSL才能回到初始状态,这意味着TIME_WAIT的典型持续时间为1-4分钟。TIME_WAIT存在的原因是:

①为实现TCP这种全双工连接的可靠释放
       TCP释放连接4次挥手过程中,假设的发起端来连接一方(图中为client)发送的ACK在网络中丢失,那么由于TCP的重传机制,另一方(图中为server)需要重发其FIN,在该FIN到达client之前,client必须维护这条连接的状态。也就是说,这条TCP连接对应的local_ip, local_port资源不能被立即释放或重新分配。直到重发的FIN达到,client也重发ACK后,该TCP连接才能断开。如果client不进入TIME_WAIT以维护其连接状态,则当server重发的FIN达到时,client的TCP传输层会以RST包响应对方,这会被对方认为有错误发生。
        ②为使旧的数据包在网络因过期而消失
       假设TCP协议中不存在TIME_WAIT状态的限制,再假设当前有一条TCP连接:local_ip, local_port, remote_ip,remote_port。我们先关闭,接着很快以相同的四元组建立一条新连接,因为TCP协议栈是无法区分前后两条TCP连接的不同的,就可能发生这样的情况:前一条TCP连接由local peer发送的数据到达remote peer后,会被该remot peer的TCP传输层当做当前TCP连接的正常数据接收并向上传递至应用层(而事实上,在我们假设的场景下,这些旧数据到达remote peer前,旧连接已断开且一条由相同四元组构成的新TCP连接已建立,因此,这些旧数据是不应该被向上传递至应用层的),从而引起数据错乱进而导致各种无法预知的诡异现象。作为一种可靠的传输协议,TCP必须在协议层面考虑并避免这种情况的发生。
       也就是说,local peer主动调用close后,此时的TCP连接进入TIME_WAIT状态,处于该状态下的TCP连接不能立即以同样的四元组建立新连接,即发起active close的那方占用的local port在TIME_WAIT期间不能再被重新分配。由于TIME_WAIT状态持续时间为2MSL,这样保证了旧TCP连接双工链路中的旧数据包均因过期(超过MSL)而消失,此后,就可以用相同的四元组建立一条新连接而不会发生前后两次连接数据错乱的情况。

TCP协议(标志位URG、PSH,定时器,连接的建立和断开)相关推荐

  1. TCP 协议标志位PSH的作用

    1. PSH 标志位 PSH 标志位TCP6个标志位中重要的一个标志.它的英文单词是 PUSH,表示"推"的意思. 了解它的作用需要首先了解缓冲区. 1.1 接收缓冲区和发送缓冲区 ...

  2. TCP报文标志位--URG,PSH调研

    1.URG:紧急位 当设置为1时,表示TCP报文中的紧急指针有效,此时告诉系统此报文段中有紧急数据,应优先传送,发送方会把紧急数据放至报文最前面,URG设置为0时,紧急指针无意义: 窗口大小为0时,也 ...

  3. TCP协议中的URG和PSH位

    相关背景知识 http://blog.csdn.net/double_happiness/article/details/74025156 在探讨TCP协议中的URG和PSH控制位时,我们先来简单的复 ...

  4. TCP协议详解之TCP Flag标志位来判断TCP会话的开始和结束

    首先回顾一下TCP标志位的具体含义. TCP Flag标志位(控制位) 一个TCP包的详细内容: TCP FLAG 标记占1.5个byte,12bit(4bit+8bit,前半个byte与Header ...

  5. 小汤学编程之JavaEE学习day01——HTTP简介、B/S与C/S应用、连接的建立与断开、Tomcat

    一.HTTP简介 1.HTTP请求报文     2.HTTP响应报文 二.B/S与C/S应用 三.连接的建立与断开 1.连接的建立(三次握手)     2.断开连接(四次挥手) 四.连接的建立与断开 ...

  6. TCP/IP 标志位 SYN ACK RST UTG PSH FIN

    三次握手:发送端发送一个SYN=1,ACK=0标志的数据包给接收端,请求进行连接,这是第一次握手:接收端收到请求并且允许连接的话,就会发送一个 SYN=1,ACK=1标志的数据包给发送端,告诉它,可以 ...

  7. TCP Flags标志位介绍

          传输控制协议(Transmission Control Protocol,TCP)是一种传输层协议.TCP使数据包从源到目的地的传输更加顺畅.它是一种面向连接的端到端协议.每个数据包由TC ...

  8. 数据连接linux网络编程之TCP/IP基础(四):TCP连接的建立和断开、滑动窗口

    在写这篇文章之前,xxx已经写过了几篇关于改数据连接主题的文章,想要了解的朋友可以去翻一下之前的文章 一.TCP段格式: TCP的段格式如下图所示 源端口号与目标端口号 源端口号和目标端口号,加上IP ...

  9. TCP控制字段标志:URG、ACK、PSH、RST、SYN、FIN

    From: http://blog.csdn.net/wangfeng2500/article/details/7650062 在TCP层,有个FLAGS字段,这个字段有以下几个标识:SYN, FIN ...

最新文章

  1. pyhon滤镜详细教程
  2. 考研编程练习----递推数列(矩阵相乘法)
  3. python 删除变量_DAY1-step4 Python变量:声明,连接变量,全局和局部
  4. pc端vnc连接android 端
  5. 一图读懂Java架构
  6. 版本交付_连续交付友好的Maven版本
  7. 用户态和核心态的转换
  8. Ubuntu 修改 ssh远程端口号
  9. php生产随机字符的代码
  10. SxsTrace工具用法
  11. 攻击服务器修改数据库,SQL服务器数据库注入式攻击解释
  12. “服务器发送了一个意外的数据包。received:3,expected:20“问题的解决方法
  13. monty python读音-PYTHON – 让quot;Monty 语言”进入自动化行业:第 1 部分
  14. Vue.js 学习笔记 十二 Vue发起Ajax请求
  15. python 列表生成式 字典生成式
  16. Spring Boot 2.0.3 使用外置 Tomcat 服务器
  17. MAC 下的SVN客户端 Versions、SmartSVN、Cornerstone
  18. Eclipse debug 的 drop to frame 的技巧
  19. 一起学些LLVM(五): 学习lli/vmir
  20. 六一儿童节,悼念天堂的小朋友

热门文章

  1. python r语言 数据分析_PythonR语言-将Python和R整合进一个数据分析流程
  2. windows + Linux 自定义模板配置 怎么使用自定义规范管理器
  3. 我是如何将系统QPS从300提升到6000的
  4. Windows学习总结(19)——Windows必备神器Cmder使用教程
  5. docker build run 卡住_还在使用第三方Docker插件?SpringBoot官方插件真香!
  6. stm32数据手册boot_STM32问题集之BOOT0和BOOT1的作用
  7. 大型网站架构系列:负载均衡详解(3)
  8. dedecms织梦上传图片302Error错误
  9. JavaScript学习笔记——事件
  10. 打车应用上马快递业务靠谱吗?