tcp报文格式详解(tcp报文格式详解例子)

TCP/Ip 卷一上有详解 TCP首部格式如下：16位源端口号 16位目的端口号32位序号32位确认序号4位首部长度 保留6位URGACKPSHRSTSYNFIN16位窗口大小16位检验和 16位紧急指针选项数据说明：（1）每个TCP段都包括源端和目的端的端口号用于寻找发送端和接收端的应用进程。这两个值加上IP首部的源端IP地址和目的端IP地址唯一确定一个TCP连接。（2）序号用来标识从TCP发送端向接收端发送的数据字节流，它表示在这个报文段中的第一个数据字节。如果将字节流看作在两个应用程序间的单向流动，则TCP用序号对每个字节进行计数。（3）当建立一个新连接时，SYN标志变1。序号字段包含由这个主机选择的该连接的初始序号ISN，该主机要发送数据的第一个字节的序号为这个ISN加1，因为SYN标志使用了一个序号。（4）既然每个被传输的字节都被计数，确认序号包含发送确认的一端所期望收到的下一个序号。因此，确认序号应当时上次已成功收到数据字节序号加1。只有ACK标志为1时确认序号字段才有效。（5）发送ACK无需任何代价，因为32位的确认序号字段和ACK标志一样，总是TCP首部的一部分。因此一旦一个连接建立起来，这个字段总是被设置，ACK标志也总是被设置为1。（6）TCP为应用层提供全双工的服务。因此，连接的每一端必须保持每个方向上的传输数据序号。（7）TCP可以表述为一个没有选择确认或否认的华东窗口协议。因此TCP首部中的确认序号表示发送方已成功收到字节，但还不包含确认序号所指的字节。当前还无法对数据流中选定的部分进行确认。（8）首部长度需要设置，因为任选字段的长度是可变的。TCP首部最多60个字节。（9）6个标志位中的多个可同时设置为1◆ URG－紧急指针有效◆ ACK－确认序号有效◆ PSH－接收方应尽快将这个报文段交给应用层◆ RST－重建连接◆ SYN－同步序号用来发起一个连接◆ FIN－发送端完成发送任务（10）TCP的流量控制由连接的每一端通过声明的窗口大小来提供。窗口大小为字节数，起始于确认序号字段指明的值，这个值是接收端期望接收的字节数。窗口大小是一个16为的字段，因而窗口大小最大为65535字节。（11）检验和覆盖整个TCP报文端：TCP首部和TCP数据。这是一个强制性的字段，一定是由发送端计算和存储，并由接收端进行验证。TCP检验和的计算和UDP首部检验和的计算一样，也使用伪首部。（12）紧急指针是一个正的偏移量，黄蓉序号字段中的值相加表示紧急数据最后一个字节的序号。TCP的紧急方式是发送端向另一端发送紧急数据的一种方式。 （13）最常见的可选字段是最长报文大小MMS，每个连接方通常都在通信的第一个报文段中指明这个选项。它指明本端所能接收的最大长度的报文段。

title: TCP 总结date: 2018-03-25 09:40:24tags:categories:-计算机网络我们都知道 TCP 是位于传输层的协议，他还有一个兄弟就是 UDP ，他们两共同构成了传输层。显然他们之间有很大的区别要不然的话在传输层只需要一个就好了。其中最重要的区别就是一个面向连接另外一个不是，这个区别就导致了他们是否能够保证稳定传输，显然不面向连接的 UDP 是没办法保证可靠传输的，他只能靠底层的网络层和链路层来保证。我们都知道网络层采用的是不可靠的 IP 协议。好吧，网络层也保证不了可靠传输，所以 UDP 保证可靠传输只能依靠链路层了。而 TCP 就好说了他不仅仅有底层的链路层的支持，还有自己的面向链接服务来保证可靠传输。当然 TCP也不仅仅就是比 UDP 多了一个可靠传输，前面也说到了这只是他们之间一个重要的区别。其实他的三个重要特性就是它们之间的区别。* 可靠传输* 流量控制* 拥塞控制TCP 主要是 确认重传机制 数据校验 数据合理分片和排序 流量控制 拥塞控制 依靠来完成可靠传输的 , 下面详细介绍这几种保证可靠传输的方式。确认重传，简单来说就是接收方收到报文以后给发送方一个 ACK 回复，说明自己已经收到了发送方发过来的数据。如果发送方等待了一个特定的时间还没有收到接收方的 ACK 他就认为数据包丢了，接收方没有收到就会重发这个数据包。好的，上面的机制还是比较好理解的，但是我们会发现一个问题，那就是如果接收方已经收到了数据然后返回的 ACK 丢失，发送方就会误判导致重发。而此时接收方就会收到冗余的数据，但是接收方怎么能判定这个数据是冗余的还是新的数据呢？这就涉及到了 TCP 的另外一个机制就是采用序号和确认号，也就是每次发送数据的时候这个报文段里面包括了当前报文段的序号和对上面的报文的确认号，这样我们的接收方可以根据自己接受缓存中已经有的数据来确定是否接受到了重复的报文段。这时候如果出现上面所说的 ACK 丢失，导致接受重复的报文段时客户端丢弃这个冗余的报文段。好现在我们大致了解了确认重传机制，但是还有些东西还没有弄清楚，也就是 TCP 真正的实现究竟是怎样的。这就是我们要解决的第一个问题就是如何确认。这里涉及到两种确认方式，分别称为 累计确认（捎带确认）和单停等协议。用一张图来快速理解，就是每发送一次数据，就进行一次确认。等发送方收到了 ACK 才能进行下一次的发送。一样的也是采用的 ACK 机制，但是注意一点的是，并非对于每一个报文段都进行确认，而仅仅对最后一个报文段确认，捎带的确认了上图中的 203 号及以前的报文。总结：从上面可以看到累计确认的效率更加高，首先他的确认包少一些那么也就是在网络中出现的大部分是需要传输的数据，而不是一半的数据一半的 ACK ，然后我们在第二张图中可以看到我们是可以连续发送多个报文段的（究竟一次性能发多少这个取决于发送窗口，而发送窗口又是由接受窗口和拥塞窗口一起来决定的。），一次性发多个数据会提高网络的吞吐量以及效率这个可以证明，比较简单这里不再赘述！结论：显然怎么看都是后者比较有优势，TCP 的实现者自然也是采用的累计确认的方式！上文中的那个特定的时间就是超时时间，为什么有这个值呢? 其实在发送端发送的时候就为数据启动了一个定时器，这个定时器的初始值就是超时时间。超时时间的计算其实有点麻烦，主要是我们很难确定一个确定的值，太长则进行了无意义的等待，太短就会导致冗余的包。TCP 的设计者们设计了一个计算超时时间的公式，这个公式概念比较多，有一点点麻烦，不过没关系我们一点点的来。首先我们自己思考如何设计一个超时时间的计算公式，超时时间一般肯定是和数据的传输时间有关系的，他必然要大于数据的往返时间（数据在发送端接收端往返一趟所用的时间）。好，那么我们就从往返时间下手，可是又有一个问题就是往返时间并不是固定的我们有如何确定这个值呢？自然我们会想到我们可以取一小段时间的往返时间的平均值来代表这一时间点的往返时间，也就是微积分的思想！好了我们找到了往返时间（RTT），接下来的超时时间应该就是往返时间再加上一个数就能得到超时时间了。这个数也应该是动态的，我们就选定为往返时间的波动差值，也就是相邻两个往返时间的差。下面给出我们所预估的超时时间（TimeOut）公式：很好，看到这里其实你已经差不多理解了超时时间的计算方式了，只不过我们这个公式不够完善，但是思路是对的。我们这时候来看看 TCP 的实现者们采用的方式。好的，这就是 TCP 实现的超时时间的方式，但是在实际的应用中并不是一直采用的这种方式。假如说我们现在网络状态非常的差，一直在丢包我们根本没必要这样计算，而是采用直接把原来的超时时间加倍作为新的超时时间。总结：好的现在我们知道了在两种情况下的超时时间的计算方式，正常的情况下我们采用的上面的比较复杂的计算公式，也就是RTT+波动值否则直接加倍上面我们看到在发送方等待一个超时重传时间后会开始重传，但是我们计算的超时重传时间也不定就很准，也就是说我们经常干的一件事就会是等待，而且一般等的时间还挺长。那么可不可以优化一下呢？当然，在 TCP 实现中是做了优化的，也就是这里说到的快速重传机制。他的原理就是在发送方收到三个冗余的 ACK 的时候，就开始重传那个报文段。那么为什么是三个冗余的 ACK 呢？注意三个冗余的 ACK 其实是四个 ACK 。我们先了解一下发送 ACK 策略，这个是RFC 5681 文档规定的。好的，那么现在我们可以看到如果出现了三个冗余的 ACK 他只可能是发生了两次情况三，也就是发送了两个比期望值大的数据。但是注意出现情况三有两种可能，一个是丢包，另外一个是乱序到达。比如说我们现在是数据乱序到达的，我们来看一下。第一种乱序情况另外一种乱序丢包情况结论: 很显然我们可以看到，如果发生了乱序有可能会出现三次冗余 ACK，但是如果发现了丢包必然会有三次冗余 ACK 发生，只是 ACK 数量可能更多但是不会比三次少在我们发现丢包以后我们需要重传，但是我们重传的方式也有两种方式可以选择分别是GBN和SR翻译过来就是拉回重传和选择重传。好其实我们已经能从名字上面看出来他们的作用方式了，拉回重传就是哪个地方没收到那么就从那个地方及以后的数据都重新传输，这个实现起来确实很简单，就是把发送窗口和接受窗口移回去，但是同样的我们发现这个方式不实用干了很多重复的事，效率低。那么选择重传就是你想到的谁丢了，就传谁。不存在做无用功的情况。结论:TCP 实际上使用的是两者的结合，称为选择确认，也就是允许 TCP 接收方有选择的确认失序的报文段，而不是累计确认最后一个正确接受的有序报文段。也就是跳过重传那些已经正确接受的乱序报文段。数据校验，其实这个比较简单就是头部的一个校验，然后进行数据校验的时候计算一遍 checkSum 比对一下。在 UDP 中，UDP 是直接把应用层的数据往对方的端口上 “扔” ，他基本没有任何的处理。所以说他发给网络层的数据如果大于1500字节,也就是大于MTU。这个时候发送方 IP 层就需要分片。把数据报分成若干片，使每一片都小于MTU.而接收方IP层则需要进行数据报的重组。这样就会多做许多事情,而更严重的是 ，由于UDP的特性,当某一片数据传送中丢失时 ， 接收方便无法重组数据报，将导致丢弃整个UDP数据报。而在 TCP 中会按MTU合理分片，也就是在 TCP 中有一个概念叫做最大报文段长度（MSS）它规定了 TCP 的报文段的最大长度，注意这个不包括 TCP 的头，也就是他的典型值就是 1460 个字节（TCP 和 IP 的头各占用了 20 字节）。并且由于 TCP 是有序号和确认号的，接收方会缓存未按序到达的数据，根据序号重新排序报文段后再交给应用层。流量控制一般指的就是在接收方接受报文段的时候，应用层的上层程序可能在忙于做一些其他的事情，没有时间处理缓存中的数据，如果发送方在发送的时候不控制它的速度很有可能导致接受缓存溢出，导致数据丢失。相对的还有一种情况是由于两台主机之间的网络比较拥塞，如果发送方还是以一个比较快的速度发送的话就可能导致大量的丢包，这个时候也需要发送方降低发送的速度。虽然看起来上面的两种情况都是由于可能导致数据丢失而让发送主机降低发送速度，但是一定要把这两种情况分开，因为前者是属于 流量控制而后者是拥塞控制，那将是我们后面需要讨论的事情。不要把这两个概念混了。其实说到流量控制我们就不得不提一下滑动窗口协议，这个是流量控制的基础。由于 TCP 连接是一个全双工的也就是在发送的时候也是可以接受的，所以在发送端和接收端同时维持了发送窗口和接收窗口。这里为了方便讨论我们就按照单方向来讨论。接收方维持一个接受窗口，发送方一个发送窗口。发送的时候要知道接受窗口还有多少空间，也就是发送的数据量不能超过接受窗口的大小，否则就溢出了。而当我们收到一个接收方的 ACK 的时候我们就可以移动接受窗口把那些已经确认的数据滑动到窗口之外，发送窗口同理把确认的移出去。这样一直维持两个窗口大小，当接收方不能在接受数据的时候就把自己的窗口大小调整为 0 发送窗口就不会发送数据了。但是有一个问题，这个时候当接收窗口再调大的时候他不会主动通知发送方，这里采用的是发送方主动询问。还是画个图看的比较直观：拥塞控制一般都是由于网络中的主机发送的数据太多导致的拥塞，一般拥塞的都是一些负载比较高的路由，这时候为了获得更好的数据传输稳定性，我们必须采用拥塞控制，当然也为了减轻路由的负载防止崩溃。这里主要介绍两个拥塞控制的方法，一个是慢开始，另外一个称为快恢复。那么问题来了，为什么需要序号呢？为什么又是三次握手而不是两次？以及什么是 SYN 洪泛攻击？这里需要说明一下的是最后的那个长长的 TIME_WAIT 状态一般是为了客户端能够发出 ACK 一般他的值是 1分钟 或者2分钟好了，今天真的写了不少，主要就是把 TCP 的可靠传输以及连接管理讲清楚了，以及里面的一下细节问题，真的很花时间。然后其他没有涉及到的就是关于 TCP 的头并没有详细的去分析，这个东西其实也不是很难，但是现在篇幅真的已经很大就先这样，头里面的都是固定的不需要太多的理解。

TCP：传输、控制、协议。TCP与UDP最大却别就在那个C上面，它充分实现了数据传输时各种控制功能。可以进行丢包重发控制，还可以对次序乱掉的数据包进行顺序控制，还能控制传输流量，这些是UDP中没有的。即T C P 提供一种面向连接的、可靠的字节流服务。TCP是一中面向有链接的协议，只有在确认对端存在的时候，才会发送分数据，从而也可以控制通信流量的浪费。什么是可靠的传输：不丢包、不损坏、不乱序、不重复。TCP通过校验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制来实现可靠传输。接收端查询就收数据TCP首部中的序号和数据长度。将自己下一步应该接受的序列号作为确认应答返送回去。就这样，通过序列号和确认应答，TCP实现可靠传输。一般使用TCP首部用于控制的字段来管理连接。一个连接的建立和断开，正常过程中，至少需要来回共7个包才能完成。TCP首部的数据结构如图所示：TCP包首部为了便于理解，忽略选项部分，固定首部通常为20个字节，将按作用分类分析。前4个字节来标识了发送方的端口号和接收方的端口号，即该数据包由谁发送，由谁接收。前2个字节标识源端口号，紧接着2个字节标识目的端口号。即发送方：(11111111,1111111)2= (65535)10，除去0~1023.即接收方：(11111111,1111111)2= (65535)10，除去0~1023.TCP是面向字节流的。在一个TCP连接中传送的字节流中的每一个字节都按顺序编号。整个要传送的字节流的起始序号必须在连接建立时设置。首部中的序号字段值则是指的是本报文段所发送的数据的第一个字节的序号。长度为4字节，序号是32bit的无符号数,序号到达232- 1后又从0开始。ack：确认序号，即确认字节的序号，更确切地说，是发送确认的一端所期望收到的下一个序号。所谓的发送确认的一端就是将确认信息发出的一端。比如第二次握手的S端就是发送确认的一端。确认序号为上次接收的最后一个字节序号加1.只有确认标志位(ACK)为1的时候，确认序号才有效。也叫首部长度，占4个bit,它指出TCP报文段的数据起始处距离TCP报文段的起始处有多远。TCP报文结构由于首部中还有长度不确定的选项字段，因此数据偏移字段是必要的。“首部长度”是4位二进制数，单位是32位字，能表示的最大十进制数字是15。(1111)2=(15)10,即是15个32位，一个32位是4个字节，因此数据偏移的最大值是154=60个字节，这也是TCP首部的最大字节。因为固定首部的存在，数据偏移的值最小为20个字节，因此选项长度不能超过40字节*（减去20个字节的固定首部）。占6位，保留为今后使用，但目前应置为0。当URG=1时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快发送（相当于高优先级的数据），而不要按原来的排队顺序来传送。例如，已经发送了很长的一个程序要在远地的主机上运行。但后来发现了一些问题，需要取消该程序的运行，因此用户从键盘发出中断命令。如果不使用紧急数据，那么这两个字符将存储在接收TCP的缓存末尾。只有在所有的数据被处理完毕后这两个字符才被交付接收方的应用进程。这样做就浪费了很多时间。当URG置为1时，应用进程就告诉TCP有紧急数据要传送。于是TCP就把紧急数据插入到本报文段数据的最前面，而在紧急数据后面的数据仍然是普通数据。这时要与首部中紧急指针（Urgent Pointer）字段配合使用。仅当ACK = 1时确认号字段才有效，当ACK = 0时确认号无效。TCP规定，在连接建立后所有的传送的报文段都必须把ACK置为1。当两个应用进程进行交互式的通信时，有时在一端的应用进程希望在键入一个命令后立即就能收到对方的响应。在这种情况下，TCP就可以使用推送（push）操作。发送方TCP把PSH置为1，并立即创建一个报文段发送出去。接收方TCP收到PSH=1的报文段，就尽快地（即“推送”向前）交付接收应用进程。而不用再等到整个缓存都填满了后再向上交付。当RST=1时，表明TCP连接中出现了严重错误（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立传输连接。RST置为1还用来拒绝一个非法的报文段或拒绝打开一个连接。在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使SYN=1和ACK=1。因此SYN=1就表示这是一个连接请求或连接接受报文。用来释放一个连接。当FIN=1时，表明此报文段的发送发的数据已发送完毕，并要求释放运输连接。占2字节。窗口值是(0，216-1)之间的整数。窗口指的是发送本报文段的一方的接受窗口（而不是自己的发送窗口）,窗口大小是给对方用的。窗口值告诉对方：从本报文段首部中的确认号算起，接收方目前允许对方一次发送的数据量（以字节为单位）。之所以要有这个限制，是因为接收方的数据缓存空间是有限的。总之，窗口值作为接收方让发送方设置其发送窗口的依据。例如，A发送了一个报文段，其确认号是3000，窗口字段是1000.这就是告诉对方B：“从3000算起，A接收缓存空间还可接受1000个字节数据，字节序号是3000-3999”，可以想象到河道的阀门。总之：窗口字段明确指出了现在允许对方发送的数据量。窗口值经常在动态变化。占2字节。检验和字段检验的范围包括首部和数据这两部分。和UDP用户数据报一样，在计算检验和时，要在TCP报文段的前面加上12字节的伪首部。伪首部的格式和UDP用户数据报的伪首部一样。但应把伪首部第4个字段中的17改为6（TCP的协议号是6）；把第5字段中的UDP中的长度改为TCP长度。接收方收到此报文段后，仍要加上这个伪首部来计算检验和。若使用TPv6,则相应的伪首部也要改变。占2字节。紧急指针仅在URG=1时才有意义，它指出本报文段中的紧急数据的字节数（紧急数据结束后就是普通数据） 。因此，在紧急指针指出了紧急数据的末尾在报文段中的位置。当所有紧急数据都处理完时，TCP就告诉应用程序恢复到正常操作。值得注意的是，即使窗口为0时也可以发送紧急数据。长度可变，最长可达40个字节。当没有使用“选项”时，TCP的首部长度是20字节。最大报文段长度(MSS:Maximum Segment Size)表示TCP传往另一端的最大块数据的长度。当一个连接建立时，连接的双方都要通告各自的MSS。当建立一个连接时，每一方都有用于通告它期望接收的MSS选项(MSS选项只能出现在SYN报文段中),如果一方不接收来自另一方的MSS值，则MSS就定为默认值536字节(这个默认值允许20字节的IP首部和20字节的TCP首部以适合576字节IP数据报) 。为什么要规定一个最大报文长度MSS呢？这并不是考虑接受方的接收缓存可能存放不下TCP报文段中的数据。实际上，MSS与接收窗口值没有关系。我们知道，TCP报文段的数据部分，至少要加上40字节的首部（TCP首部20字节和IP首部20字节，这里还没有考虑首部中的可选部分）才能组装成一个IP数据报。若选择较小的MSS长度，网络的利用率就降低。设想在极端情况下，当TCP报文段只含有1字节的数据时，在IP层传输的数据报的开销至少有40字节（包括TCP报文段的首部和IP数据报的首部）。这样，对网络的利用率就不会超过1/41。到了数据链路层还要加上一些开销。但反过来，若TCP报文段非常长，那么在IP层传输时就有可能要分解成多个短数据报片。在终点要把收到的各个短数据报片组成成原来的TCP报文段，当传输出错时还要进行重传，这些也都会使开销增大。因此，MSS应尽可能大些，只要在IP层传输时不需要分片就行。由于IP数据报所经历的路径是动态变化的，因此在这条路径上确定的不需要的分片的MSS，如果改走另一条路径就可能需要进行分片。因此最佳的MSS是很难确定的。在连接过程中，双方都把自己能够支持的MSS写入这一字段，以后就按照这个数值传输数据，两个传送方向可以有不同的MSS值。若主机未填写这一项，则MSS的默认值是536字节长。因此，所有在互联网上的主机都应该接受的报文段长度是536+20（固定首部长度）=556字节。后来又增加了几个选项如窗口扩大选项、时间戳选项等。窗口扩大选项是为了扩大窗口。我们知道，TCP首部中窗口字段长度是16位，因此最大的窗口大小为64K字节。虽然这对早期的网络是足够用的，但对于包含卫星信道的网络，传播时延和宽带都很大，要获得高吞吐量需要更大的窗口大小。窗口扩大选项占3字节，其中有一个字节表示移位值S。新的窗口值等于TCP首部中的窗口位数从16增大到（16+S）。移位值允许使用的最大值是14，相当于窗口最大值增大到2（16+14）-1=230-1。窗口扩大选项可以在双方初始建立TCP连接时进行协商。如果连接的某一端实现了窗口扩大，当它不再需要扩大其窗口时，可发送S=0选项，使窗口大小回到16。时间戳选项占10字节，其中最主要的字段是时间戳字段（4字节）和时间戳回送回答字段（4字节）。时间戳选项有以下两个概念：第一、 用来计算往返时间RTT。发送方在发送报文段时把当前时钟的时间值放入时间戳字段，接收方在确认该报文段时把时间戳字段复制到时间戳回送回答字段。因此，发送方在收到确认报文后，可以准确地计算出RTT来。第二、 用于处理TCP序号超过232的情况，这又称为防止序号绕回PAWS。我们知道，TCP报文段的序号只有32位，而每增加232个序号就会重复使用原来用过的序号。当使用高速网络时，在一次TCP连接的数据传送中序号很可能被重复使用。例如，当使用1.5Mbit/s的速度发送报文段时，序号重复要6小时以上。但若用2.5Gbit/s的速率发送报文段，则不到14秒钟序号就会重复。为了使接收方能够把新的报文段和迟到很久的报文段区分开，则可以在报文段中加上这种时间戳。从功能和性能的角度去理解三次握手建立连接第一次：C向S发送一个建立连接的请求。此过程中携带一些报文属性信息，这些信息，存在于报文首部，有初始化用的信息，比如，有用于认证的信息。初始化信息：如报文序列号、SYN：TCP在数据通信之前，通过TCP首部发送的一个SYN标志位，作为建立连接的请求等待接收方确认应答。如果S发来确认应答，则认为可以进行数据通信，否则，就不能进行通信。TCP规定：****SYN=1的报文段不能携带数据，但是要消耗掉一个序号：seq=x。这个时候C进入SYN-SENT(同步已发送)状态。第二次：S收到C请求后，如果同意建立连接，则向C返回确认信息：将SYN、ACK都置1，确认号为ack=seq+1(seq来自客户端)，并携带自己的初始化，同时用于认证的信息S。同理：SYN=1的报文段不能携带数据，但是要消耗掉一个序号：seq=y。这个时候S进入SYN-RCVD(同步已接收)状态。C收到S返回的确认信息后，进入ESTABLISHED(已建立连接)的状态，第三次：C收到S返回的确认信息后，向S再一次发送确认报文。ACK置为1，确认号ack=seq+1(seq来自S),自己的seq=x+1。TCP规定：ACK报文可以携带数据。但是，如果不携带数据，则不消耗序号，这时，下一数据报文段的序号仍是seq=x+1。服务器收到客户端返回的确认信息后，也进入ESTABLISHED(已建立连接)的状态，从功能角度去考虑前两次握手，从性能的角度去理解为什么需要第三次握手。有第三次，是考虑到一种错误情况：假设C发了一请求建立连接的报文，长时间未收到S的确认报文，则C会重发，这个时候S与之建立连接、完成数据通信、关闭了连接，这个时候C第一发出的请求建立连接的报文到达了S,S则会等待C发送数据，实际上C已经CLOSED了，S就一直在这等待，浪费资源，确切地说，应该是至少四次数据交互才能实现一个连接的彻底关闭。关闭连接，需要四个报文来指示关闭。TCP是全双工通信的，所以在一端发送数据完毕后，还具有接收另一端的数据的能力，这就所谓的半关闭。四次挥手举个例子：如果C的数据已经发送完毕，C是不能立即关闭的，因为建立连接的通信双方是平等的。C首先告诉S：“数据发送完毕“，这个消息在TCP报文的首部由FIN来标识，让S知道C是准备断开连接了。这是第一次挥手。S收到C发来的FIN标识的报文后，要给C端恢复一个确认FIN的消息，告诉C说，知道你的数据发完了。这是第二次挥手。这个时候，如果S端的数据也发送完毕了，就给C发一个FIN=1报文。这是第三次挥手。C收到S发来的FIN标识的报文后，要给S端恢复一个确认FIN的消息，告诉C说，知道你的数据发完了。这是第四次挥手。然后就彻底断开连接了。TCP的状态变迁图

主要特点：面向连接、面向字节流、全双工通信、通信可靠。优缺点：应用场景：要求通信数据可靠时，即 数据要准确无误地传递给对方。如：传输文件：HTTP、HTTPS、FTP等协议；传输邮件：POP、SMTP等协议ps：首部的前 20 个字节固定，后面有 4n 字节根据需要增加。故 TCP首部最小长度 = 20字节（最大60个字节）。TCP报头中的源端口号和目的端口号同IP数据报中的源IP与目的IP唯一确定一条TCP连接。重要字段：客户端与服务器来回共发送三个TCP报文段来建立运输连接，三个TCP报文段分别为：（1）客户端A向服务器B发送的TCP请求报段“SYN=1,seq=x”；（2）服务器B向客户端A发送的TCP确认报文段“SYN=1,ACK=1,seq=y,ack=x+1”；（3）客户端A向服务器B发送的TCP确认报文段“ACK=1,seq=x+1,ack=y+1”。ps：在建立TCP连接之前，客户端和服务器都处于关闭状态（CLOSED）,直到客户端主动打开连接，服务器才被动打开连接（处于监听状态 = LISTEN）,等待客户端的请求。TCP 协议是一个面向连接的、安全可靠的传输层协议，三次握手的机制是为了保证能建立一个安全可靠的连接。通过上述三次握手，双方确认自己与对方的发送与接收是正常的，就建立起一条TCP连接，即可传送应用层数据。ps：因 TCP提供的是全双工通信，故通信双方的应用进程在任何时候都能发送数据；三次握手期间，任何1次未收到对面的回复，则都会重发。为什么两次握手不行呢？结论：防止服务器接收了早已经失效的连接请求报文，服务器同意连接，从而一直等待客户端请求，最终导致形成死锁、浪费资源。ps：SYN洪泛攻击：（具体见下文）为什么不需要四次握手呢？SYN 同步序列编号(Synchronize Sequence Numbers) 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK确认序号标志消息响应。这样在客户机和服务器之间才能建立起可靠的 TCP 连接，数据才可以在客户机和服务器之间传递。如何来解决半连接攻击？如何来解决全连接攻击？请注意，现在 TCP 连接还没有释放掉。必须经过时间等待计时器设置的时间 2MSL（MSL：最长报文段寿命）后，客户端才能进入到 CLOSED 状态，然后撤销传输控制块，结束这次 TCP 连接。当然如果服务器一收到 客户端的确认就进入 CLOSED 状态，然后撤销传输控制块。所以在释放连接时，服务器结束 TCP 连接的时间要早于客户端。TCP是全双工的连接，必须两端同时关闭连接，连接才算真正关闭。简言之，客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器才会发送 FIN 连接释放报文，对方确认后就完全关闭了TCP连接。举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。ps：设想这样一个情景：客户端已主动与服务器建立了 TCP 连接。但后来客户端的主机突然发生故障。显然，服务器以后就不能再收到客户端发来的数据。因此，应当有措施使服务器不要再白白等待下去。这就需要使用TCP的保活计时器。基本原理：tcp11种状态及变迁其实基本包含在正常的三次握手和四次挥手中，除开CLOSING。正常的三次握手包括4中状态变迁：服务器打开监听(LISTEN)->客户端先发起SYN主动连接标识->服务器回复SYN及ACK确认->客户端再确认即三次握手TCP连接成功。这里边涉及四种状态及变迁：正常的四次握手包含6种tcp状态变迁，如主动发起关闭方为客户端：客户端发送FIN进入FIN_WAIT1 -> 服务器发送ACK确认并进入CLOSE_WAIT(被动关闭)状态->客户端收到ACK确认后进入FIN_WAIT2状态 -> 服务器再发送FIN进入LAST_ACK状态 -> 客户端收到服务器的FIN后发送ACK确认进入TIME_WAIT状态 -> 服务器收到ACK确认后进入CLOSED状态断开连接 -> 客户端在等待2MSL的时间如果期间没有收到服务器的相关包，则进入CLOSED状态断开连接。CLOSING状态：连接断开期间，一般是客户端发送一个FIN，然后服务器回复一个ACK，然后服务器发送完数据后再回复一个FIN，当客户端和服务器同时接受到FIN时，客户端和服务器处于CLOSING状态，也就是此时双方都正在关闭同一个连接。在进入CLOSING状态后，只要收到了对方对自己发送的FIN的ACK，收到FIN的ACK确认就进入TIME_WAIT状态，因此，如果RTT(Round Trip Time TCP包的往返延时)处在一个可接受的范围内，发出的FIN会很快被ACK从而进入到TIME_WAIT状态，CLOSING状态持续的时间就特别短，因此很难看到这种状态。我们知道网络层，可以实现两个主机之间的通信。但是这并不具体，因为，真正进行通信的实体是在主机中的进程，是一个主机中的一个进程与另外一个主机中的一个进程在交换数据。IP协议虽然能把数据报文送到目的主机，但是并没有交付给主机的具体应用进程。而端到端的通信才应该是应用进程之间的通信。应用场景：UDP协议比TCP协议的效率更高，TCP协议比UDP协议更加安全可靠。下面主要对数据传输出现错误/无应答/堵塞/超时/重复等问题。注意：TCP丢包：TCP是基于不可靠的网路实现可靠传输，肯定会存在丢包问题。如果在通信过程中，发现缺少数据或者丢包，那边么最大的可能性是程序发送过程或者接受过程中出现问题。总结：为了满足TCP协议不丢包，即保证可靠传输，规定如下：注意：TCP丢包有三方面的原因，一是网络的传输质量不好，二是安全策略，三是服务器性能瓶颈先理解2个基础概念：发送窗口、接收窗口工作原理：注意点：关于滑动窗口的知识点：滑动窗口中的数据类型：ARQ解决的问题：出现差错时，让发送方重传差错数据：即 出错重传类型：流量控制和拥塞控制解决的问题：当接收方来不及接收收到的数据时，可通知发送方降低发送数据的效率：即 速度匹配流量控制：注意：拥塞控制：慢开始与拥塞避免：快重传和快恢复：补充：流量控制和拥塞控制的区别什么情况造成TCP粘包和拆包？解决TCP粘包和拆包的方法：传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。最简单的方式是在应用层模仿传输层TCP的可靠性传输。下面不考虑拥塞处理，可靠UDP的简单设计。https://www.jianshu.com/p/65605622234bhttp://www.open-open.com/lib/view/open1517213611158.htmlhttps://blog.csdn.net/dangzhangjing97/article/details/81008836https://blog.csdn.net/qq_30108237/article/details/107057946https://www.jianshu.com/p/6c73a4585eba

考虑最简单的情况：两台主机之间的通信。这个时候只需要一条网线把两者连起来，规定好彼此的硬件接口，如都用 USB、电压 10v、频率 2.4GHz 等，这一层就是物理层，这些规定就是物理层协议。我们当然不满足于只有两台电脑连接，因此我们可以使用交换机把多个电脑连接起来，如下图：这样连接起来的网络，称为局域网，也可以称为以太网（以太网是局域网的一种）。在这个网络中，我们需要标识每个机器，这样才可以指定要和哪个机器通信。这个标识就是硬件地址 MAC。硬件地址随机器的生产就被确定，永久性唯一。在局域网中，我们需要和另外的机器通信时，只需要知道他的硬件地址，交换机就会把我们的消息发送到对应的机器。这里我们可以不管底层的网线接口如何发送，把物理层抽离，在他之上创建一个新的层次，这就是数据链路层。我们依然不满足于局域网的规模，需要把所有的局域网联系起来，这个时候就需要用到路由器来连接两个局域网：但是如果我们还是使用硬件地址来作为通信对象的唯一标识，那么当网络规模越来越大，需要记住所有机器的硬件地址是不现实的；同时，一个网络对象可能会频繁更换设备，这个时候硬件地址表维护起来更加复杂。这里使用了一个新的地址来标记一个网络对象：IP 地址。通过一个简单的寄信例子来理解 IP 地址。我住在北京市，我朋友 A 住在上海市，我要给朋友 A 写信：因此，这里 IP 地址就是一个网络接入地址（朋友 A 的住址），我只需要知道目标 IP 地址，路由器就可以把消息给我带到。在局域网中，就可以动态维护一个 MAC 地址与 IP 地址的映射关系，根据目的 IP 地址就可以寻找到机器的 MAC 地址进行发送。这样我们不需管理底层如何去选择机器，我们只需要知道 IP 地址，就可以和我们的目标进行通信。这一层就是网络层。网络层的核心作用就是提供主机之间的逻辑通信。这样，在网络中的所有主机，在逻辑上都连接起来了，上层只需要提供目标 IP 地址和数据，网络层就可以把消息发送到对应的主机。一个主机有多个进程，进程之间进行不同的网络通信，如边和朋友开黑边和女朋友聊微信。我的手机同时和两个不同机器进行通信。那么当我的手机收到数据时，如何区分是微信的数据，还是王者的数据？那么就必须在网络层之上再添加一层：运输层：运输层通过 socket（套接字），将网络信息进行进一步的拆分，不同的应用进程可以独立进行网络请求，互不干扰。这就是运输层的最本质特点：提供进程之间的逻辑通信。这里的进程可以是主机之间，也可以是同个主机，所以在 android 中，socket 通信也是进程通信的一种方式。现在不同的机器上的应用进程之间可以独立通信了，那么我们就可以在计算机网络上开发出形形式式的应用：如 web 网页的 http，文件传输 ftp 等等。这一层称为应用层。应用层还可以进一步拆分出表示层、会话层，但他们的本质特点都没有改变：完成具体的业务需求。和下面的四层相比，他们并不是必须的，可以归属到应用层中。最后对计网分层进行小结：这里需要注意的是，分层并不是在物理上的分层，而是逻辑上的分层。通过对底层逻辑的封装，使得上层的开发可以直接依赖底层的功能而无需理会具体的实现，简便了开发。这种分层的思路，也就是责任链设计模式，通过层层封装，把不同的职责独立起来，更加方便开发、维护等等。TCP 并不是把应用层传输过来的数据直接加上首部然后发送给目标，而是把数据看成一个字节 流，给他们标上序号之后分部分发送。这就是 TCP 的面向字节流特性：面向字节流的好处是无需一次存储过大的数据占用太多内存，坏处是无法知道这些字节代表的意义，例如应用层发送一个音频文件和一个文本文件，对于 TCP 来说就是一串字节流，没有意义可言，这会导致粘包以及拆包问题，后面讲。前面讲到，TCP 是可靠传输协议，也就是，一个数据交给他，他肯定可以完整无误地发送到目标地址，除非网络炸了。他实现的网络模型如下：对于应用层来说，他就是一个可靠传输的底层支持服务；而运输层底层采用了网络层的不可靠传输。虽然在网络层甚至数据链路层就可以使用协议来保证数据传输的可靠性，但这样网络的设计会更加复杂、效率会随之降低。把数据传输的可靠性保证放在运输层，会更加合适。可靠传输原理的重点总结一下有：滑动窗口、超时重传、累积确认、选择确认、连续 ARQ。停止等待协议要实现可靠传输，最简便的方法就是：我发送一个数据包给你，然后你跟我回复收到，我继续发送下一个数据包。传输模型如下：这种“一来一去”的方法来保证传输可靠就是停止等待协议（stop-and-wait）。不知道还记不记得前面 TCP 首部有一个 ack 字段，当他设置为 1 的时候，表示这个报文是一个确认收到报文。然后再来考虑另一种情况：丢包。网络环境不可靠，导致每一次发送的数据包可能会丢失，如果机器 A 发送了数据包丢失了，那么机器 B 永远接收不到数据，机器 A 永远在等待。解决这个问题的方法是：超时重传。当机器 A 发出一个数据包时便开始计时，时间到还没收到确认回复，就可以认为是发生了丢包，便再次发送，也就是重传。但重传会导致另一种问题：如果原先的数据包并没有丢失，只是在网络中待的时间比较久，这个时候机器 B 会受到两个数据包，那么机器 B 是如何辨别这两个数据包是属于同一份数据还是不同的数据？这就需要前面讲过的方法：给数据字节进行编号。这样接收方就可以根据数据的字节编号，得出这些数据是接下来的数据，还是重传的数据。在 TCP 首部有两个字段：序号和确认号，他们表示发送方数据第一个字节的编号，和接收方期待的下一份数据的第一个字节的编号。停止等待协议的优点是简单，但缺点是信道利用率太低。假定AB之间有一条直通的信道来传送分组这里的TD是A发送分组所需要的时间（显然TD = 分组长度 / 数据速率）再假定TA是B发送确认分组所需要的时间（A和B处理分组的时间都忽略不计）那么A在经过TD+RTT+TA时间后才能发送下一个分组，这里的RTT是往返时间，因为只有TD是采用来传输有用的数据（这个数据包括了分组首部，如果可以知道传输更精确的数据的时间，可以计算的更精确），所有信道利用率为为了提高传输效率，发送方可以不使用低效率的停止等待协议，而是采用流水线传输：就是发送方可以连续的发送多个分组，不必每发完一个分组就停下来等待对方的确认。这样可使信道上一直有数据不间断地在传送。显然这种传输方式可以获得很高的信道利用率停止等待协议已经可以满足可靠传输了，但有一个致命缺点：效率太低。发送方发送一个数据包之后便进入等待，这个期间并没有干任何事，浪费了资源。解决的方法是：连续发送数据包。也就是下面介绍的连续ARQ协议和滑动窗口协议连续 ARQ 协议模型如下：和停止等待最大的不同就是，他会源源不断地发送，接收方源源不断收到数据之后，逐一进行确认回复。这样便极大地提高了效率。但同样，带来了一些额外的问题:发送是否可以无限发送直到把缓冲区所有数据发送完？不可以。因为需要考虑接收方缓冲区以及读取数据的能力。如果发送太快导致接收方无法接受，那么只是会频繁进行重传，浪费了网络资源。所以发送方发送数据的范围，需要考虑到接收方缓冲区的情况。这就是 TCP 的流量控制。解决方法是：滑动窗口。基本模型如下：在 TCP 的首部有一个窗口大小字段，他表示接收方的剩余缓冲区大小，让发送方可以调整自己的发送窗口大小。通过滑动窗口，就可以实现 TCP 的流量控制，不至于发送太快，导致太多的数据丢失。连续 ARQ 带来的第二个问题是：网络中充斥着和发送数据包一样数据量的确认回复报文，因为每一个发送数据包，必须得有一个确认回复。提高网络效率的方法是：累积确认。接收方不需要逐个进行回复，而是累积到一定量的数据包之后，告诉发送方，在此数据包之前的数据全都收到。例如，收到 1234，接收方只需要告诉发送方我收到 4 了，那么发送方就知道 1234 都收到了。第三个问题是：如何处理丢包情况。在停止等待协议中很简单，直接一个超时重传就解决了。但，连续 ARQ 中不太一样。例如：接收方收到了 123 567，六个字节，编号为 4 的字节丢失了。按照累积确认的思路，只能发送 3 的确认回复，567 都必须丢掉，因为发送方会进行重传。这就是GBN（go-back-n)思路。但是我们会发现，只需要重传 4 即可，这样不是很浪费资源，所以就有了：选择确认 SACK。在 TCP 报文的选项字段，可以设置已经收到的报文段，每一个报文段需要两个边界来进行确定。这样发送方，就可以根据这个选项字段只重传丢失的数据了。第四个问题是：拥塞控制的问题也是通过窗口的大小来控制的，但是检测网络满不满是个挺难的事情，所以 TCP 发送包经常被比喻成往谁管理灌水，所以拥塞控制就是在不堵塞，不丢包的情况下尽可能的发挥带宽。水管有粗细，网络有带宽，即每秒钟能发送多少数据；水管有长度，端到端有时延。理想状态下，水管里面的水 = 水管粗细 * 水管长度。对于网络上，通道的容量 = 带宽 * 往返时延。如果我们设置发送窗口，使得发送但未确认的包为通道的容量，就能撑满整个管道。如图所示，假设往返时间为 8 秒，去 4 秒，回 4 秒，每秒发送一个包，已经过去了 8 秒，则 8 个包都发出去了，其中前四个已经到达接收端，但是 ACK 还没返回，不能算发送成功，5-8 后四个包还在路上，还没被接收，这个时候，管道正好撑满，在发送端，已发送未确认的 8 个包，正好等于带宽，也即每秒发送一个包，也即每秒发送一个包，乘以来回时间 8 秒。如果在这个基础上调大窗口，使得单位时间可以发送更多的包，那么会出现接收端处理不过来，多出来的包会被丢弃，这个时候，我们可以增加一个缓存，但是缓存里面的包 4 秒内肯定达不到接收端课，它的缺点会增加时延，如果时延达到一定程度就会超时重传TCP 拥塞控制主要来避免两种现象，包丢失和超时重传，一旦出现了这些现象说明发送的太快了，要慢一点。具体的方法就是发送端慢启动，比如倒水，刚开始倒的很慢，渐渐变快。然后设置一个阈值，当超过这个值的时候就要慢下来慢下来还是在增长，这时候就可能水满则溢，出现拥塞，需要降低倒水的速度，等水慢慢渗下去。拥塞的一种表现是丢包，需要超时重传，这个时候，采用快速重传算法，将当前速度变为一半。所以速度还是在比较高的值，也没有一夜回到解放前。到这里关于 TCP 的可靠传输原理就已经介绍得差不多。最后进行一个小结：当然，这只是可靠传输的冰山一角，感兴趣可以再深入去研究