TCP/IP协议族详解(五) Domi●Cat

本系列文章是教程:TCP、IP协议族详解的学习笔记。

该系列大概分为下面几个部分:

  • 1、TCP/IP协议4层结构以及每层的作用
  • 2、IP协议详解
  • 3、ARP协议和RARP协议详解
  • 4、ICMP协议详解
  • 5、TCP协议详解
  • 6、UDP协议详解

本文主要介绍 TCP/IP 网络体系中网络层的 TCP 协议。另外推荐一篇文章,写得很不错。

在介绍 TCP 协议之前,让我们先了解一下传输层。

1、网络层与传输层关系

先举一个生活中的例子,假如我在京东上购买了一个物品,发货方为上海的某个商家,收货方就是我的公司地址,比如说是:双击省老铁市666区没毛病软件园A座。 但是A座这栋楼很大,快递员不知道我具体在哪一层哪个室,这里就需要一个门牌号,比如说666号

那么,套路上面的例子,双击省老铁市666区没毛病软件园A座这个地址就类似IP地址,它工作于网络层, 它能定位到一块具体的位置,也是就 A 座这台电脑,在 A 座这栋楼里面的各个公司就是计算机中的各个进程,每个公司(进程)都占有一个门牌号, 这个门牌号就是端口号,端口号这个概念就属于传输层

两台主机间通信条件:

  1. 本地主机 IP
  2. 远程主机 IP

两台主机进程间通信条件:

  1. 本地主机 IP
  2. 本地进程 端口
  3. 远程主机 IP
  4. 远程进程 端口

因此,可以简单的理解:网络层(这里指 IP 协议)提供主机之间的逻辑通信,传输层(这里指 TCP 或者 UDP 协议)提供提供进程之间的逻辑通信。

2、传输层协议详解

传输层功能

  • 分段及封装应用层送来的数据,例如:我们运送水果,不可能一个一个的运送,一般都是将大堆苹果装车后一车一车的运送, 每一车装多少个就是分段数据,装车后要用布封起来保鲜就是封装数据。
  • 提供端到端的传输服务,即源主机端口到目的主机端口进行通信。
  • 在发送主机与接收主机之间构建逻辑通信,如果源主机分别开启Telnet、http访问远程主机的telnet服务和http服务, 那么传输层就提供这样一个机制,它构建了两个对应的逻辑通道。

关于端口

端口

端口的范围

端口的大小目前是2个byte,也就是说最大有 65536 个端口,在 0~65535 这个范围内,我们又把它分成三个部分:

  • 熟知端口(著名端口):0-1023,由ICANN指派和控制(例如:80 端口、22 端口等)
  • 注册端口:1024-49151,IANA不指派也不控制,但须注册(例如:3306 端口,即 mysql 端口)
  • 动态端口(短暂端口):49152-65535,IANA 不指派也不控制,无须注册,可以分配给你自己的应用

3、TCP协议详解

核心:TCP 协议负责将数据分段成 TCP 报文段(每一段报文作为传递给 IP 层的数据)、重组 TCP 报文段将数据还原。

TCP协议的特点

  • 面向连接:通讯双方交换数据之前必须要先建立连接
  • 可靠性:提供了多种确保可靠性的机制
  • 字节流服务:8bit(1byte)为最小单位构成的字节流(所以不存在粘包的概念)

套接字

套接字(socket)它是ip地址和端口号的一个组合(例如:192.168.2.172:80),它是TCP连接的最基本的、抽象化的一个对象, 也就是TCP连接的端点,一个 TCP 连接有两个端点。

socket套接字

TCP数据传输过程

在底层的实现中,TCP发送端和接收端都有对应的缓存,分别是发送缓存、接收缓存,应用层传递给传输层的数据并不一定立即就发送出去了, 而是先放入缓存中,然后等待最合适的时机(网络通畅、对端用空闲等等)再把数据发送出去。同理,接收端也是一样的道理。

另外,需要注意,传输层在向 IP 层传递数据是,是以分组为单位的,而不是按整个字节流来发送,TCP 协议把若干字节构成一个分组后, 再投递给 IP 层,这种的分组就称为报文段(Segment),因此,我们常常说 TCP 报文段就是这样来的。

举例来说:我去菜市场买了一根很长的黄瓜(现在的黄瓜怎么都长那么长- -),太长不好切,那就先把黄瓜切成一段一段的, 然后再对每一段切片。这个切成一段的过程就类似 TCP 数据分段,分段后再交给 IP 层。

TCP数据传输

让我们在深入一层,拿上图来说,首先我们要知道两个概念:字节号和报文段序号。

  • 字节号,就是上图中环形缓存中未发送的字节,每个字节所对应的编号(一个格子表示一个字节),字节号的范围是(0~2^32-1),生成方式随机(依赖于系统内核的实现方式)。 例如:要发送一个6000byte的数据,并且给第一个字节随机到了一个字节号为1057,那么这6000个字节的数据所对应的字节号就是:1057~7056

  • 报文段序号,它是基于前面的字节号,其实就是分段后,第一个字节的字节号 例如:把上面的6000字节的数据分为5个报文发送,前4个报文每个发送1000个字节,最后一个发送2000个字节。那么这5个报文段的序号依次是:1057、2056、3056、4056、5056。

4、TCP报文段首部格式

它与IP协议首部格式类型,也分为固定部分(20byte)和可选部分。

TCP首部格式

和前面一样,通过抓包来逐个解释每个字段。这里访问一个网站,抓包结果如下: TCP首部抓包结果

上面两个结果是一次TCP通讯的往返信息,下面以上图中第三个包作为例子解释各个字段:

  • 第1、2个字节:值为dc ea,十进制为56554,表示源端口,一般如果源端没有bind一个端口的话,这个端口将是动态的,比如我们访问一个http网站,第一次访问可能是56554,刷新网页后端口可能就发生了变化。
  • 第3、4个字节:值为00 50,十进制为80(也就是大家熟悉的http服务端口),表示目的端口。 注意一下这里的Stream index:1,可以看做成一个五元组(源IP、源端口、目的IP、目的端口、传输协议)的编号,只要其中一个发送变化,这个流索引号就会发生变化。 另外,这里有个TCP segment Len:0,表示这个报文没有传递数据,因为上图抓的是三次握手的包,所以没有数据长度。
  • 第5到8个字节:表示报文段序号(图中显示的是相对位置,至于相对位置和绝对段序号是怎么转换的,我暂时也不太清楚,这里留一个疑问)
  • 第9到12个字节:表示确认号,也是相对序号(三次握手),即告诉对方我期望收到你的下一个报文段的序号值。 比如发送的报文段A的序号是100,那么对端收到后确认,并要求你下一个发送的报文段的序号要为100+1=101,这个101就在对端返回的报文段B中的确认号部分。同理,发送端对接收端的数据也要做确认。

    流程如下:

      发送端 ----         报文A(序号100)          ---> 接收端
      发送端 <---     报文B(序号200,确认号101)     ---- 接收端
      发送端 ----下一个数据报文段(序号101,确认号201) ---> 接收端
    
  • 第13、14个字节:这里需要特殊处理一下:

    • 前4bit表示首部长度,和IP首部一样,也是以4字节为单位(所以tcp头部最大为15*4=60byte);
    • 后12个bit中,只用到后面6bit,前面的保留(不过现在也有用到前面的bit位了),关于后6个bit每位表达的意义,后面做详细介绍
  • 第15、16个字节:表示窗口大小,最大是65536个字节,也就是64kb。 注意:这个值很重要,下面会有窗口机制的详细介绍。
  • 第17、18个字节:校验和,它校验的范围包括tcp首部和数据两个部分。在计算检验和时,要在 TCP 报文段的前面加上 12 字节的伪首部(伪首部就是ip地址)。
  • 第19、20个字节:紧急指针,紧急指针指出在本报文段中的紧急数据的最后一个字节的序号。同时 URG比特位要置1。
  • 可选选项:主要介绍MSS(maximum Segment Size),它用来限定TCP报文段数据部分的最大长度,不包含TCP首部。 这里要只要MTU( Maximum Transmit Unit)这个概念,即最大传输单元,是物理接口(数据链路层)提供给其上层(IP层)最大一次能传输的数据大小,以以太网为例,缺省MTU=1500byte,这是以太网接口对IP层的约束。 例如:IP层有<=1500byte的字节要发送,则只需要一个IP包就可以发送了,如果>1500byte,就需要IP层分片,每个分片有相同的IP首部。

    一般情况下,有以下等式

    MSS = MTU-TCP首部(20byte)-IP首部(byte)

6bits 每个比特位介绍

  • 紧急比特 URG: 当 URG=1 时,表明紧急指针字段有效。它告诉系统此报文段中有紧急数据,应尽快传送(相当于高优先级的数据)。
  • 确认比特 ACK: 只有当 ACK = 1 时确认号字段才有效。当 ACK = 0 时,确认号无效
  • 推送比特 PSH (Push): 接收 TCP 收到推送比特置 1 的报文段,就尽快地交付给接收应用进程,而不再等到整个缓存都填满了后再向上交付。
  • 复位比特 RST (Reset): 当 RST=1 时,表明 TCP 连接中出现严重差错(如由于主机崩溃或其他原因),必须释放连接,然后再重新建立运输连接
  • 同步比特 SYN: 同步比特 SYN 置为 1,就表示这是一个连接请求或连接接受报文,一般是tcp建立连接的第一个tcp报文。
  • 终止比特 FIN (Final): 用来释放一个连接。当FIN = 1 时,表明此报文段的发送端的数据已发送完毕,并要求释放运输连接。一般是tcp终止连接的最后一个报文。

5、TCP三次握手

tcp使用三次握手机制建立TCP连接,三次握手流程如下: TCP三次握手

下面详解讲解这三个过程:

  • 连接发起方首先发送一个 SYN,SEQ=X(这个报文的序号是系统随机的),发送的报文A: SYN,SEQ=X(假如X=1000)
  • 接收方收到SYN后,会确认这个SYN,并返回SYN+ACK,它确认发送方的SYN,同时也会向发送方也发送一个SYN确认请求,而且还会告知对方,我的窗口大小(可以理解成能接受数据的缓存的大小)。 返回的报文B:SEQ=Y(假如Y=5000),SYN,ACK=X+1(也就是报文A的SEQ+1 = 1001)
  • 发起方收到接受方的SYN+ACK后,也会对对方的SYN确认,同时也会告知我的窗口大小。 返回的报文C:SEQ=1001,ACK=Y+1(也就是报文B的SEQ+1=5001)

三次握手就是一个“礼尚往来”的过程。比如说:小明有2个苹果,小红有2个梨子,他俩都想要吃对方的水果,那么用三次握手解释如下:

  • 小明给了小红一个苹果,用来搭讪,小明:“给你一个苹果,可好吃了”(SEQ=苹果1)
  • 小红吃了一个苹果后,觉得很好吃,于是给了小明一个梨子作为回礼,但是小红还想继续吃,就撒娇说:“人家还想吃苹果”(SEQ=梨子1,ACK=苹果2)
  • 小明一听,哟,有戏啊,于是就把最后的一个苹果给了小红,同时又跟小红说:“要不你把最后那个梨子也给我吧”(SEQ=苹果2,ACK=梨子2)

于是小明和小红就勾搭上了,从此性福快乐的在一起了。

6、TCP四次挥手

tcp使用四次挥手机制终止TCP连接,四次挥手流程如下: TCP四次挥手

下面详解讲解这四个过程:

  • 客户方起方首先发送一个FIN,SEQ=X(这个报文的序号是系统随机的)。 发送的报文A: SYN,SEQ=X(假如X=1000)
  • 服务方收到FIN后,会确认这个FIN,并返回ACK,但是这里并没有立即返回FIN给客户方,此时,只能说客户方到服务方的连接释放了,这个TCP连接处于“半关闭”状态,服务方还是能否传送数据到客户方,反之不行。 返回的报文B:SEQ=Y(假如Y=5000),ACK,ACK=X+1(也就是报文A的SEQ+1 = 1001)
  • 一段时间后,服务方才发送FIN给客户方,通知客户方,我也要终止连接了。 发送的报文C:SEQ=Z(假如Z=7000),FIN,ACK,ACK=X+1(也就是报文A的SEQ+1=1001)
  • 最后,客户端确认服务方发送过来的FIN,此时,这个TCP连接就完全终止了。 返回的报文D:ACK,SEQ=X+1(1001),ACK=Z+1(7001)

还是上面的例子,小红和小明勾搭一段时间后,小明要分手,分手前决定把之前交换的水果都还回去。

  • 小明(客户方)还了一个梨子给小红,并且提出了分手(SEQ=梨子1)
  • 小红答应了,也还了一个苹果给小明,并且要求把最后的梨子也换回来(SEQ=苹果1,ACK=梨子2)
  • 小明在之前吃了一个梨子,发现没有梨子了,就假装没反应,心里寻思着去哪里弄个梨回来,这时候小红又发来通告,“赶紧还我例子,还了赶紧分手”(SEQ=苹果1,ACK=梨子2,FIN)
  • 小明最终搞到一个梨子,并还给了小红,同时要求小红还最后的苹果(SEQ=梨子2,ACK=苹果2)

从此,二人分道扬镳。

7、TCP确认和窗口机制

确认机制

假如要发送一批TCP报文,每个报文的SN(Sequence number)分别为:1,235,790,1500,当发送790这个报文的时候, 对方通过校验和检测,发现数据错误,就会返回一个带ACK的报文,且ACK id = 790,要求发送方重新发送一次790,这就是TCP重传确认机制。 TCP的报文到达确认(ACK),是对接收到的数据的最高序列号的确认,并向发送端返回一个下次接收时期望的TCP数据包的序列号(Ack Number) (注意:这里一定要理解好ACK以及ACK number的意义)。例如,主机A发送的当前数据序号是400,数据长度是100, 则接收端收到后会返回一个确认号是501的确认号给主机A。

举一个例子:

假如要发送1000字节的数据,tcp分片后假设有5个分片,分别是:

  • 第1个分片:1-200,共200字节
  • 第2个分片:201-400,共200字节
  • 第3个分片:401-700,共300字节
  • 第4个分片:701-900,共200字节
  • 第5个分片:901-1000,共100字节

当发送方发送了1、2、3个分片后,接收方确实时,发现第2个包出现错误,就会返回一个ack包(ack number=2),发送方收到这个ack包后, 对比它自己的最高序列号,发现2小于3,就认为是第2个分片错误,需要重传,然后发送方就会重传第2个分片。

TCP提供的确认机制,可以在通信过程中可以不对每一个TCP数据包发出单独的确认包(Delayed ACK机制), 而是在传送数据时,顺便把确认信息传出,这样可以大大提高网络的利用率和传输效率。 同时,TCP的确认机制,也可以一次确认多个数据报,例如,接收方收到了201,401,701的数据报, 则只需要对701的数据包进行确认即可,对701的数据包的确认也意味着701之前的所有数据包都已经确认,这样也可以提高系统的效率。

窗口机制

tcp利用窗口大小进行流量控制,一般情况下,它是由数据接收端定义的。它用来控制对方发送的数据量,单位为字节。 TCP 连接的一端根据设置的缓存空间大小确定自己的接收窗口大小,然后通知对方以确定对方的发送窗口的上限。

举一个例子:有个水池,水池有进水口和出水口,进水的管子根据粗细分为很多根,通过水池现在的空闲大小, 我们要动态计算需要用哪种粗细的管子来加水。如果水池现在没水了,就要用更粗一点的管子,同时供水方就加大供水, 如果水池快满了,就要切换成细一点的管子,并通知供水方减小供水。 那么上面的水池就是tcp缓存,粗细不同的管子就是就类似是窗口大小,通过窗口大小来达到流量控制的目的。

其实TCP在整个发送过程中,也在度量当前的网络状态,目的是为了维持一个健康稳定的发送过程,比如拥塞控制。 因此,数据是在某些机制的控制下进行传输的,就是窗口机制。发送端的发送窗口是基于接收端的接收窗口来计算的。

下图可以生动描述窗口机制的工作原理: TCP窗口机制

我们把上面的数据分为四种类型:

  1. 已经发送且对端已经确认
  2. 已发送,对端等待确认(此时还在窗口内)
  3. 在窗口内,但未发送
  4. 在窗口外,未发送

TCP窗口就是这样逐渐滑动,发送新的数据,滑动的依据就是发送数据已经收到ACK,确认对端收到,才能继续窗口滑动发送新的数据。 可以看到窗口大小对于吞吐量有着重要影响,同时ACK响应与系统延时又密切相关。

需要说明的是:如果发送端的窗口过大会引起接收端关闭窗口,处理不过来。 反之,如果窗口设置较小,结果就是不能充分利用带宽,所以仔细调节窗口对于适应不同延迟和带宽要求的系统很重要。

关于TCP的窗口机制,可以参考博客TCP 协议中的 Window Size与吞吐量