传输控制协议(TCP)、IP协议

传输控制协议(TCP)

传输控制协议( Transmission Control Protocol)，简称TCP协议，它在原有IP协议基础上，增加了确认重发、滑动窗口和复用/解复用等机制，提供一种可靠的、面向连接的字节流服务。

1.TCP的特点

TCP协议的特点如下所述。

1. 字节流的服务：使用TCP协议进行传输的应用程序之间传输的数据可视为无结构的字节流，基于字节流的服务没有字节序问题的困扰。
2. 面向连接的服务：在数据进行传输之前,TCP协议需要先建立连接，之后的TCP报文在此连接的基础上传输。
3. 可靠传输服务:基于校验和应答重发机制保证传输的可靠性。接收方对接收到的报文进行校验和计算，如果有误，不发送确认应答，发送方在超时后会自动重发此报文。
4. 缓冲传输：缓冲传输可以延迟传送应用层的数据，允许将应用程序需要传送的数据积到一定的数量才进行集中发送。
5. 全双工传输：各主机TCP协议以全双工的方式进行数据流交换。
6. 流量控制：TCP协议的滑动窗口机制，支持主机间的端到端的流量控制。

2.TCP如何保证可靠传输

1. TCP在传输有效信息前要求通信双方必须先握手，建立连接才能通信。（打电话和QQ发消息进行对比）
2. TCP的接收方收到数据包会ack给发送方，若发送方未收到ack会丢包重传
3. TCP的有效数据内容会附带校验，以防止内容在传递过程中损坏
4. TCP会根据网络带宽来自动调节适配效率（滑动窗口技术）
5. 发送方会给各分割报文编号，接收方会校验编号，一旦顺序错误即会重传。

3.TCP的数据格式

TCP在IP协议的基础上进行传输数据，TCP数据在IP报文中的位置，如图所示。

TCP数据在IP报文中的位置

TCP数据包含头部和数据两部分，其数据格式如下图所示。主要有源端口号、目的端口号、序列号、确认号、头部长度、标志位、窗口尺寸、TCP校验和、紧急指针和选项等字段。

TCP报文数据格式

• 源端口号和目的端口号：这两个字段均为16位的长度,表示发送端和接收端的端口,用于确认发送端和接收端的应用程序。发送端的IP地址和端口号及接收端的IP地址和端口号可以确认一个在 Internet上的TCP连接。
• 序列号：seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。
• 确认序号：ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，ack=seq+1。
• 头部长度：表示TCP头部的长度，由于TCP的数据有可选字段，头部长度用于表示头部的长度。此字段的长度为4位，表示的是32位字长的数据(4字节)。因此TCP的头部最长为60个字节，如果没有可选字段通常为20字节。（标识TCP头部有多少个32bit字，最大为15，所以TCP头部最长60字节）
• 保留位：6位长度没有使用，必须设为0。
• 控制位：6b，用做控制位，可以多个位一起设置，含义在下表进行说明。
• 窗口尺寸：窗口尺寸也称接收窗口大小，表示本机上TCP协议可以接收的以字节为单位的数目，本字段为16b大小。

• 校验和：16b。 用于校验TCP传输数据的正误，包括TCP头和所有数据，TCP的数据必须强制校验。
• 紧急指针：16b。 只有设置了URG位才有效，它指出了紧接紧急数据的字节的顺序编号。
• 选项：经常使用的为最大分段长度MSS (Maximum Segment Size)。TCP 连接通常在第一个通信的报文中指明这个选项，它指明当前主机所能接收的最大报文长度。

4.建立连接的三次握手

主机A和主机B要使用TCP协议进行通信，需要先建立条TCP连接，如下图所示。为了建立一条TCP的连接，主机A和B需要进行三次通信过程(通常称为“三次握手”，three way handshake)。

• 第一次握手：A随机选取一个序列号作为自己的初始序号发送给B，并进入SYN_SENT状态，等待服务器确认；
• 第二次握手：B使用ack对A的数据包进行确认，因为已经收到了序列号为x的数据包，准备接收序列号为x+1的包，所以ack=x+1，同时B告诉A自己的初始序列号，就是seq=y，此时服务器进入SYN_RECV状态；
• 第二次握手：A告诉B收到了B的确认消息并准备建立连接，A自己此条消息的序列号是x+1，所以seq=x+1，而ack=y+1是表示A正准备接收B序列号为y+1的数据包。客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

需要注意的是：

1. 不要将确认序号ack与标志位中的ACK搞混了。
2.  确认方ack=发起方seq+1，两端配对。
3. 建立连接的条件：客户端主动发起connect前，服务器需事先处于listen阶段。

为什么A还要发送一次确认呢?这主要是为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。

• 所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常情况。A发出连接请求,但因连接请求报文丢失而未收到确认。于是A再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。A共发送了两个连接请求报文段，其中第一个丢失，第二个到达了B。没有“已失效的连接请求报文段”
• 现假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，以致延误到连接释放以后的某个时间才到达B。本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，就误认为是A又发出一次新的连接请求。于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立了。
• 由于现在A并没有发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据。但B却以为新的运输连接已经建立了，并一直等待A发来数据。B的许多资源就这样白白浪费了。
• 采用三次握手的办法可以防止上述现象的发生。例如在刚才的情况下，A不会向B的确认发出确认。B由于收不到确认,就知道A并没有要求建立连接。

5.释放连接的四次挥手过程

建立一个TCP连接需要3次握手，而终止一个TCP连接需要4次挥手。如下图所示：

1. 客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2. 服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3. 客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4. 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5. 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6. 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

需要注意的是：

1. 服务器或者客户端都可以主动发起关闭；
2. 这些握手协议已经封装在TCP协议内部，socket编程接口平时不用管。

6.TCP状态转换

这个图N多人都知道，它排除和定位网络或系统故障时大有帮助，但是怎样牢牢地将这张图刻在脑中呢？那么你就一定要对这张图的每一个状态，及转换的过程有深刻的认识，不能只停留在一知半解之中。下面对这张图的11种状态详细解析一下，以便加强记忆！不过在这之前，先回顾一下TCP建立连接的三次握手过程，以及 关闭连接的四次握手过程。

 

• CLOSED：表示初始状态。
• LISTEN：该状态表示服务器端的某个SOCKET处于监听状态，可以接受连接。
• SYN_SENT：这个状态与SYN_RCVD遥相呼应，当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，随即进入到了SYN_SENT状态，并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。
• SYN_RCVD: 该状态表示接收到SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂。此种状态时，当收到客户端的ACK报文后，会进入到ESTABLISHED状态。
• ESTABLISHED：表示连接已经建立。
• FIN_WAIT_1:  FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。区别是：

            FIN_WAIT_1状态是当socket在ESTABLISHED状态时，想主动关闭连接，向对方发送了FIN报文，此时该socket进入到                FIN_WAIT_1状态。

            FIN_WAIT_2状态是当对方回应ACK后，该socket进入到FIN_WAIT_2状态，正常情况下，对方应马上回应ACK报文，所              以FIN_WAIT_1状态一般较难见到，而FIN_WAIT_2状态可用netstat看到。

• ESTABLISHED：表示连接已经建立。
• FIN_WAIT_2：主动关闭链接的一方，发出FIN收到ACK以后进入该状态。称之为半连接或半关闭状态。该状态下的socket只能接收数据，不能发。
• TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文，等2MSL后即可回到CLOSED可用状态。如果FIN_WAIT_1状态下，收到对方同时带 FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。
• CLOSING: 这种状态较特殊，属于一种较罕见的状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的 ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢？如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。
• CLOSE_WAIT: 此种状态表示在等待关闭。当对方关闭一个SOCKET后发送FIN报文给自己，系统会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，察看是否还有数据发送给对方，如果没有可以 close这个SOCKET，发送FIN报文给对方，即关闭连接。所以在CLOSE_WAIT状态下，需要关闭连接。
• LAST_ACK: 该状态是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，即可以进入到CLOSED可用状态。

7.滑动窗口 (TCP流量控制)

介绍UDP时我们描述了这样的问题：如果发送端发送的速度较快，接收端接收到数据后处理的速度较慢，而接收缓冲区的大小是固定的，就会丢失数据。TCP协议通过“滑动窗口（Sliding Window）”机制解决这一问题。看下图的通讯过程：

滑动窗口

1. 发送端发起连接，声明最大段尺寸是1460，初始序号是0，窗口大小是4K，表示“我的接收缓冲区还有4K字节空闲，你发的数据不要超过4K”。接收端应答连接请求，声明最大段尺寸是1024，初始序号是8000，窗口大小是6K。发送端应答，三方握手结束。
2. 发送端发出段4-9，每个段带1K的数据，发送端根据窗口大小知道接收端的缓冲区满了，因此停止发送数据。
3. 接收端的应用程序提走2K数据，接收缓冲区又有了2K空闲，接收端发出段10，在应答已收到6K数据的同时声明窗口大小为2K。
4. 接收端的应用程序又提走2K数据，接收缓冲区有4K空闲，接收端发出段11，重新声明窗口大小为4K。
5. 发送端发出段12-13，每个段带2K数据，段13同时还包含FIN位。
6. 接收端应答接收到的2K数据（6145-8192），再加上FIN位占一个序号8193，因此应答序号是8194，连接处于半关闭状态，接收端同时声明窗口大小为2K。
7. 接收端的应用程序提走2K数据，接收端重新声明窗口大小为4K。
8. 接收端的应用程序提走剩下的2K数据，接收缓冲区全空，接收端重新声明窗口大小为6K。
9. 接收端的应用程序在提走全部数据后，决定关闭连接，发出段17包含FIN位，发送端应答，连接完全关闭。

• 上图在接收端用小方块表示1K数据，实心的小方块表示已接收到的数据，虚线框表示接收缓冲区，因此套在虚线框中的空心小方块表示窗口大小，从图中可以看出，随着应用程序提走数据，虚线框是向右滑动的，因此称为滑动窗口。
• 从这个例子还可以看出，发送端是1K、1K地发送数据，而接收端的应用程序可以两K两K地提走数据，当然也有可能一次提走3K或6K数据，或者一次只提走几个字节的数据。也就是说，应用程序所看到的数据是一个整体，或说是一个流（stream），在底层通讯中这些数据可能被拆成很多数据包来发送，但是一个数据包有多少字节对应用程序是不可见的，因此TCP协议是面向流的协议。而UDP是面向消息的协议，每个UDP段都是一条消息，应用程序必须以消息为单位提取数据，不能一次提取任意字节的数据，这一点和TCP是很不同的。

8.基于TCP通信的服务模式

1. 具有公网IP地址的服务器（或者使用动态IP地址映射技术）;
2. 服务器端socket、bind、listen后处于监听状态;
3. 客户端socket后，直接connect去发起连接;
4. 服务器收到并同意客户端接入后会建立TCP连接，然后双方开始收发数据，收发时是双向的，而且双方均可发起；
5. 双方均可发起关闭连接。

9.常见面试题

【问题1】为什么连接的时候是三次握手，关闭的时候却是四次握手？

• 答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

• 答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假想网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

【问题3】为什么不能用两次握手进行连接？

• 答：3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
• 现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

【问题4】如果已经建立了连接，但是客户端突然出现故障了怎么办？

• TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

IP协议

IP协议是TCP/IP协议中最重要的协议,它为TCP、UDP、ICMP等协议提供传输的通路。IP层的主要目的是提供子网的互联形成较大的网络,使不同的子网之间能传输数据。
IP层主要有如下作用:

• 数据传送:将数据从一个主机传输到另一个主机。
• 寻址:根据子网划分和IP地址,发现正确的目的主机地址。
• 路由选择:选择数据在互联网上的传送路径
• 数据报文的分段:当传送的数据大于MTU时,将数据进行分段发送和接收并组装。

IP数据的格式如下图所示,不包含选项字段,其头部的长度为20个字节。

IP头部数据格式

• IP数据报的首部长度和数据长度都是可变长的，但总是4字节的整数倍。对于IPv4，4位版本字段是4。4位首部长度的数值是以4字节为单位的，最小值为5，也就是说首部长度最小是4x5=20字节，也就是不带任何选项的IP首部，4位能表示的最大值是15，也就是说首部长度最大是60字节。8位TOS字段有3个位用来指定IP数据报的优先级（目前已经废弃不用），还有4个位表示可选的服务类型（最小延迟、最大?吐量、最大可靠性、最小成本），还有一个位总是0。总长度是整个数据报（包括IP首部和IP层payload）的字节数。每传一个IP数据报，16位的标识加1，可用于分片和重新组装数据报。3位标志和13位片偏移用于分片。TTL（Time to live)是这样用的：源主机为数据包设定一个生存时间，比如64，每过一个路由器就把该值减1，如果减到0就表示路由已经太长了仍然找不到目的主机的网络，就丢弃该包，因此这个生存时间的单位不是秒，而是跳（hop）。协议类型指示上层协议是TCP、UDP、ICMP还是IGMP。然后是校验和，只校验IP首部，数据的校验由更高层协议负责。IPv4的IP地址长度为32位。

数据包的封装解封过程

下图所示为使用TCP协议的应用程序的数据传输过程，用户数据由主机A发送给主机B，数据封装在TCP的数据部分。

• 发送的过程是一个封包的过程。在主机A上，在传输层，用户发送的数据增加TCP头部，用户数据封装在TCP的数据部分。在IP层增加IP的头部数据，TCP 的数据和头部都封装在IP层的数据部分。IP层将数据传输给网络设备的驱动程序，以太网增加头部和尾部后，发送到以太网上。
• 接收数据的过程是一个解封包的过程。在主机B上，驱动程序从以太网上接收到数据，然后将数据去除头部和尾部并进行CRC校验后，将正确的数据传递给IP层。IP层剥去IP头，进行校验，将数据发送给其上层TCP层。TCP则将TCP的包头剥去，根据应用程序的标识符判断是否发送给此应用程序。在主机B上的应用程序会得到干净的有效数据，然后进行处理。

TCP通信的数据封装解封过程