TCP/IP详解学习笔记--TCP（传输控制协议）

1.概述

     TCP提供了一种可靠的面向连接的字节流运输层服务。

     TCP将用户数据打包成报文段，它发送后启动一个定时器，另一端收到的数据进行确认，对失序的数据重新排序，丢弃重复数据，TCP提供端到端的流量控制，并计算和验证一个强制性的端到端的检验和。

     许多流行的应用程序如：Telnet， Rlogin， FTP，SMTP 都使用TCP。

• TCP的主要特点：
• • TCP是面向连接的运输层协议
  • 每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点的
  • TCP提供可靠交付的服务
  • TCP提供全双工通信
  • 面向字节流。
  • • 面向字节流的含义：虽然应用程序和TCP交互是一次一个数据块，但TCP把应用程序交下来的数据仅仅是一连串的无结构的字节流

      TCP面向流的概念

2.TCP首部

     TCP报文段的首部格式如图所示：

     各自段的含义：

• 源端口和目的端口：各占两个字节，端口是运输层与应用层的服务接口，运输层的复用和分解功能都要通过端口才能实现。
• 序号：占4字节，序号范围是[0,2^32-1]。TCP把在一个TCP连接中传输的数据流中的每一个字节都编上一个序号。
• 确认号：是期望收到对方的下一个报文段的数据第一个字节的序号
• • 若确认号 == N,则表明到序号N-1为止的所有数据都已正确收到。
• 首部长度：最大60字节
• 保留：6bit, 均为0.
• 紧急URG：当URG=1时，表示报文段中有紧急数据，应尽快传送，而不要按照原来的排队顺序传送，与“紧急指针”字段配合使用。
• 确认比特ACK：只有当ACK = 1时确认号才有效。
• 推送比特PSH：当发送端PSH=1时，并立即创建一个报文段发送出去，接收TCP收到PSH为1的报文段后，不在等到整个缓存都填满后在向上交付，而是尽快的交付给应用进程。
• 复位比特（RST）：复位比特也称重建比特或重置比特。当RST=1时，表明TCP连接中出现严重差错，必须释放连接，然后在重新建立连接。
• 同步比特SYN：在建立连接是用来同步序号。SYN=1， ACK=0表示一个连接请求报文段。SYN=1，ACK=1表示同意建立连接。
• 终止比特FIN：用来释放一个连接。FIN=1时，表明此报文段的发送端的数据已经发送完毕，并要求释放运输连接。
• 窗口：用来控制对方发送的数据量。单位为字节。TCP连接的一端根据设置的缓存空间大小确定自己的接收窗口大小。然后通知发放已确定的发送窗口上限。
• • 窗口的值是经常在动态变化
• 检验和：检验和字段检验的范围包括首部和数据这两部分
• 紧急指针：紧急指针在URG=1时才有效，它指出本报文段中的紧急数据的字节数。
• 选项：长度可变，最长可达40字节

3.最大报文长度MSS

     MSS默认值为536字节。注：MSS=TCP报文段长度-TCP首部长度

4.TCP连接的建立

     

     设主机B运行一个服务器进程，它先发出一个被动打开命令，告诉它的TCP要准备接收客户进程的连续请求，然后服务进程就处于听的状态。不断检测是否有客户进程发起连续请求，如有，作出响应。设客户进程运行在主机A中，他先向自己的TCP发出主动打开的命令，表明要向某个IP地址的某个端口建立运输连接，过程如下：

     1）主机A的TCP向主机B的TCP发出连接请求报文段，其首部中的同步比特SYN应置1，同时选择一个序号x，表明在后面传送数据时的第一个数据字节的序号是x。

     2）主机B的TCP收到连接请求报文段后，如同意，则发挥确认。在确认报文段中应将SYN置为1，确认号应为x+1，同时也为自己选择一个序号y

     3）主机A的TCP收到此报文段后，还要向B给出确认，其确认号为y+1

     4）主机A的TCP通知上层应用进程，连接已经建立，当主机B的TCP收到主机A的确认后，也通知上层应用进程，连接建立。

 

CLOSED : 进程处于关闭状态。

SYN-SENT : 客户进程进入同步已发送状态。

ESTAB-LISHEND : 进程已经入已建立连接状态，之后可以传送数据了。

LISTEN : 服务器进程处于收听状态。

SYN-RCVD : 服务器进程进入同步收到状态。

5.TCP连接的释放

     

     在数据传输完毕之后，通信双方都可以发出释放连接的请求。释放连接的过程为如上图所示：

     1）数据传输结束后，主机A的应用进程先向其TCP发出释放连接请求，不在发送数据。TCP通知对方要释放从A到B的连接，将发往主机B的TCP报文段首部的终止比特FIN置为1，序号u等于已传送数据的最后一个字节的序号加1。

     2）主机B的TCP收到释放连接通知后发出确认，其序号为u+1，同时通知应用进程，这样A到B的连接就释放了，连接处于半关闭状态。主机B不在接受主机A发来的数据；但主机B还向A发送数据，主机A若正确接收数据仍需要发送确认。

     3）在主机B向主机A的数据发送结束后，其应用进程就通知TCP释放连接。主机B发出的连接释放报文段必须将终止比特置为1，并使其序号w等于前面已经传送过的数据的最后一个字节的序号加 1，还必须重复上次已发送过的ACK=u+1。

     4）主机A对主机B的连接释放报文段发出确认，将ACK置为1，ACK=w+1, seq=u+1。这样才把从B到A的反方向连接释放掉，主机A的TCP再向其应用进程报告，整个连接已经全部释放。

ESTAB-LISHEND : 进程已经入已建立连接状态，可以传送数据。

FIN-WAIT1 : 客户端进程进入终止等待1的状态。

FIN-WAIT2 : 客户端进程进入终止等待2的状态。

TIME-WAIT: 客户端进程进入时间等待（服务器的重传）的状态。

CLOSED : 进程处于关闭状态。

CLOSED-WAIT: 服务器进程进入关闭等待状态。

LAST-ACK: 服务器进行最后一次关闭确认。

注意两个状态：

<1> CLOSED-WAIT: 服务器进程进入关闭等待状态。

服务器等待关闭状态：服务器接收到客户端关闭连接的请求，而自身还未想客户端发送关闭连接请求的这段时间。

通常情况下，CLOSE_WAIT状态的持续时间应该很短，但是如果服务器有很多数据需要传输或读写时，就不能关闭连接，此时就会出现连接长时间处于CLOSE_WAIT状态的情况。

<2> TIME-WAIT: 客户端进程进入时间等待（服务器的重传）的状态。

<客户端完全关闭状态>：客户端收到服务器断开连接的请求后，会向服务器确认收到分组，表示自己已经收到，你可以关闭连接了。但是该确认分组可能由于网络问题收不到，而出现重传的情况。所以客户端必须要等待一会。此时客户端等待完全关闭的时间就为TIME-WAIT时期。

 

6.注意的问题

          需要三次握手（还要再发送一次确认）的原因：

为了防止已失效的连接请求报文段突然又传到了服务器B，导致服务器误认为客户端想请求连接而发生连接的错误。主要目的防止server端一直等待，浪费资源。

产生错误的场景：

在两次握手的前提下，A发出连接请求，但因为丢失了，故而不能收到B的确认。于是A重新发出请求，然后收到确认，建立连接，数据传输完毕后，释放连接，A发了2个，一个丢掉，一个到达，没有“已失效的报文段”。

但是，某种情况下，A发出的第一个连接请求在某个节点滞留了，延误到达B。假设此时B已经释放连接，那么B在收到此实现的连接请求后，就误认为A又发出一次连接请求，在两次握手的情况下（A发生请求，B接受请求并确认），B就认为A又发出一次新连接请求。此时B就又给A发生一个确认，表示同意建立连接。因为是两次握手，A收到后，也不再次发出确认连接。此时B会等待A发送的数据，而A本来就没有要求发送数据，肯定也无动于衷。此时B的资源就被浪费了。

为什么三次握手能够处理这个错误场景？

采用三次握手的话，A收到B的确认后，由于A本来就不想发送数据，所以A就不发送确认，而B收不到确认，也就知道A并没有要求建立连接。

四次释放：B收到连接释放报文段后就立即发送确认，然后就进入close-wait状态，此时TCP服务器进程就通知高层应用进程，因而从A到B的连接就释放了。此时是“半关闭”状态。即A不可以发送给B，但是B可以发送给A。

此时，若B没有数据报要发送给A了，其应用进程就通知TCP释放连接，然后发送给A连接释放报文段，并等待确认。

A发送确认后，进入time-wait，注意，此时TCP连接还没有释放掉，然后经过时间等待计时器设置的2MSL后，A才进入到close状态。

为什么要等待呢?

①、为了保证A发送的最后一个ACK报文段能够到达B。即最后这个确认报文段很有可能丢失，那么B会超时重传，然后A再一次确认，同时启动2MSL计时器，如此下去。如果没有等待时间，发送完确认报文段就立即释放连接的话，B就无法重传了（连接已被释放，任何数据都不能出传了），因而也就收不到确认，就无法按照步骤进入CLOSE状态，即必须收到确认才能close。

②、防止“已失效的连接请求报文段”出现在连接中。经过2MSL，那些在这个连接持续的时间内，产生的所有报文段就可以都从网络中消失。即在这个连接释放的过程中会有一些无效的报文段滞留在楼阁结点，但是呢，经过2MSL这些无效报文段就肯定可以发送到目的地，不会滞留在网络中。这样的话，在下一个连接中就不会出现上一个连接遗留下来的请求报文段了。

可以看出：B结束TCP连接的时间比A早一点，因为B收到确认就断开连接了，而A还得等待2MSL.

为什么是四次释放：

解释原因：

TCP建立连接要进行3次握手,而断开连接要进行4次,这是由于TCP的半关闭造成的,因为TCP连接是全双工的(
即数据可在两个方向上同时传递)所以进行关闭时每个方向上都要单独进行关闭,这个单方向的关闭就叫半关闭.
关闭的方法是一方完成它的数据传输后,就发送一个FIN来向另一方通告将要终止这个方向的连接.当一端收到一个FIN,它必须
通知应用层TCP连接已终止了这个方向的数据传送,发送FIN通常是应用层进行关闭的结果.

另一种解释：

这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。

 （在tcp连接握手时为何ACK是和SYN一起发送，这里ACK却没有和FIN一起发送呢。原因是因为tcp是全双工模式，接收到FIN时意味将没有数据再发来，但是还是可以继续发送数据。）


7.TCP的有限状态机

     连接的建立和释放所要求的步骤可以用一个有限状态机来表达，该状态机有11种状态。每一种状态中都存在一些合法的事件，当合法事件发生的时候，可能需要采取某个动作。当其他事件发生的时候，则报告一个错误。

状 态

描 述

CLOSED

关闭状态，没有连接活动或正在进行

LISTEN

监听状态，服务器正在等待连接进入

SYN RCVD

收到一个连接请求，尚未确认

SYN SENT

已经发出连接请求，等待确认

ESTABLISHED

连接建立，正常数据传输状态

FIN WAIT 1

（主动关闭）已经发送关闭请求，等待确认

FIN WAIT 2

（主动关闭）收到对方关闭确认，等待对方关闭请求

TIMED WAIT

完成双向关闭，等待所有分组死掉

CLOSING

双方同时尝试关闭，等待对方确认

CLOSE WAIT

（被动关闭）收到对方关闭请求，已经确认

LAST ACK

（被动关闭）等待最后一个关闭确认，并等待所有分组死掉

TCP建立与释放的变迁如图所示：

 

 

• 客户进程变迁的过程（粗实线）
• • 连接建立：设一个主机的客户进程发起连接请求（主动打开），这时本地TCP实体就创建传输控制快（TCB），发送一个SYN为1的报文，进入SYN_SENT状态。当收到来自进程的SYN和ACK时，TCP就发送出三次握手中的最后一个ACK，进而进入连接已经建立的状态ESTABLISHED。
  • 连接释放：设运行客户进程主机本地TCP实体发送一个FIN置为1的报文，等待着确认ACK的到达，此时状态变为FIN_WAIT_1。当运行客户进程主机收到确认ACK时，则一个方向的连接已经关闭。状态变成FIN_WAIT_2。当运行客户进程的主机收到运行服务器进程的主机发送的FIN置为1的报文后，应响应确认ACK时，这是另一个连接关闭。但此时TCP还要等待一段时间后才删除原来建立的连接记录。返回到初始的CLOSED状态，这是为了保证原来连接上的所有分组都从网络中消失了。
• 服务器进程变迁的过程（粗虚线）
• • 连接建立：服务器进程发出被动打开，进入监听状态LISTEN。当收到SYN置为1的连接请求报文后，发送确认ACK，并且报文中的SYN也置为1，然后进入SYN_RCVD状态。在收到三次握手最后一个确认ACK时，就转为ESTABLISHED状态。
  • 连接释放：当客户进程的数据已经传送完毕。就发出FIN置为1的报文给服务器进程，进入CLOSE_WAIT状态。服务器进程发送FIN报文段给客户进程，状态变为LAST_ACK状态。当收到客户进程的ACK时，服务器进程就释放连接。删除连接记录。回到原来的CLOSED状态。

原文链接：http://www.cnblogs.com/newwy/p/3234536.html和http://blog.csdn.net/qq276592716/article/details/19762121