标签：可靠 参考 ima prot 挥手 定时 超时重传 recv 还需要
TCP报文格式图：
上图中有几个字段需要重点介绍下：
（1）序号：Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。
（2）确认序号：Ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，Ack=Seq+1。
（3）标志位：共6个，即URG、ACK、PSH、RST、SYN、FIN等，具体含义如下：
（A）URG：紧急指针（urgent pointer）有效。
（B）ACK：确认序号有效。
（C）PSH：接收方应该尽快将这个报文交给应用层。
（D）RST：重置连接。
（E）SYN：发起一个新连接。
（F）FIN：释放一个连接。
需要注意的是：
（A）不要将确认序号Ack与标志位中的ACK搞混了。
（B）确认方Ack=发起方Req+1，两端配对。
TCP(Transmission Control Protocol) 传输控制协议
TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接
位码即tcp标志位,有6种标示:
1）SYN(synchronous建立联机)
2）ACK(acknowledgement 确认)
3）PSH(push传送)
4）FIN(finish结束)
5）RST(reset重置)
6）URG(urgent紧急)
Sequence number(顺序号码)
Acknowledge number(确认号码)
establish 建立，创建
所谓三次握手（Three-Way Handshake）即建立TCP连接，是指建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立。在socket编程中，这一过程由客户端执行connect来触发，整个流程如下图所示：
（1）第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。
（2）第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack (number )=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。
（3）第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。
在三次握手过程中，Server发送SYN-ACK之后，收到Client的ACK之前的TCP连接称为半连接（half-open connect），此时Server处于SYN_RCVD状态，当收到ACK后，Server转入ESTABLISHED状态。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，由于源地址是不存在的，因此，Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。SYN攻击时一种典型的DDOS攻击，检测SYN攻击的方式非常简单，即当Server上有大量半连接状态且源IP地址是随机的，则可以断定遭到SYN攻击了，使用如下命令可以让之现行：
#netstat -nap | grep SYN_RECV
随着时间的流逝，计算机帝国的子民耐不住寂寞，他们好想去外面的世界看看，去其他的计算机家中串串门，他们经常抱怨，为什么那些官员可以互相聊天，而我们只能自己对自己说话.
这些抱怨传到了计算机国王的耳中，国王也很头痛啊，他也想让子民相互沟通，畅聊无阻，可是不同计算机运行着不同的操作系统，他们在表达同一种信息的时候采用的方式千差万别，很难统一啊，官员们也是费了好大劲才把那么几个操作系统的通信搞定，更何谈万千子民了.
这一次，国王召开会议与大臣一起讨论这个问题，最终一致认为成立网络专研小组，专门研究此问题
成立专家组之后，专家立即开始讨论如何使不同计算机建立通信，通过大量的考察不同的操作系统，专家们历经千辛万苦最终制定了统一标准——TCP/IP 协议族（注意：TCP/IP不是一个协议，而是一系列协议的总和），这个家族里包含了许多协议，比如常见的TCP协议，UDP协议
一次奇异的聊天
专家组把协议给国王看了看，国王非常高兴，马上派人把TCP/IP协议族中的所有协议分发给万千子民并给每一位子民拉了一根网线，子民们收到也非常高兴，各自研究其协议了
上官天宇和司马剑就是其中两位（下称上官和司马），数天后，在得知上官的地址（对应IP和端口）后，司马决定用可靠传输的TCP和上官进行通信，因为他不想在第一次聊条中漏掉任何文字
可是这个TCP有几个比较讨厌的就是聊天之前要做很多准备工作，有两步（真实的有三步，这里是为了体现两次握手的缺陷）
第一步： 他要发送一条建立连接的消息告诉对方咱两要通信了
第二步： 对方收到这个消息后，要回复他一个确认消息
上面两步（两次握手）做完了，两人才能够通信
于是，司马通过遵守TCP协议给上官天宇发了个”你好”,过了一会儿，他见上官没给他发确认消息
于是他就按照TCP的超时重传机制[简单的说就是在一定的时间后，如果对方没有回应，就认为这个消息发送失败，要重新发送],然后司马就重新发了一个消息给上官了
过了一小会，上官发来了确认消息，里面写着：“我收到了”（这个时候两次握手已经完成，两个人可以进行聊天了）
然后上官也给司马发了一个“你好”，相互聊了几句，就关闭了连接（四次挥手在下篇说）
殊不知过了一会，司马又收到聊了上官的确认消息,司马心中很纳闷，我没给他再发消息啊？喜欢探究原因的他把这个事情上报给TCP/IP的酋长了
酋长带着问题来到了宫廷，见了专家组，专家组也很纳闷，想了许久，一个资深的元老突然说道，我们的设计可能有问题，现在我们的TCP是两次连接后就可以进行通信了，现在有这么一种情况，当A发送一个消息给B，这个消息由于网络的原因，阻塞在某个节点了，如下图
然后阻塞的时间很长，超出了咱们设定超时重发时间，那么A就会认为这个消息丢失了，然后重新发送
当A和B通信完成后，这个之前被A认为”失效的消息“到达了B，而对于B而言，以为这是一个新的请求连接消息，就向A发了一次确认（这就可以解释司马有收到了一次的确认消息了），而对于A而言，他认为他没有给B再次的发消息（因为上次的通话已经结束了），所以A不会理睬这条确认，但是B则会一直在傻傻的等待着A的消息
这就导致了B的时间被白白浪费（对于服务器而言，就是CPU等资源的一种浪费），这样是万万不可的，这就是为什么不能两次握手的原因
专家组的人一致赞同这个观点，然后几个人还做了几个实验，结论是确实是这个原因导致的，最后专家组坐在一块讨论如何修改这个TCP协议，元老发话了，其实修改也很简单，再加一次通信（握手）就行了，如下图
就是说A最后还要给B发一个确认，还是上次的那个例子，如果A不给B发第三次确认消息，那么B就认为A并没给他发消息，B也就不会在那里傻傻的等待了。最后酋长带着答案和修改草稿回到了部落。
所谓四次挥手（Four-Way Wavehand）即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发，整个流程如下图所示：
由于TCP连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭，上图描述的即是如此。
（1）第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
（2）第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。
（3）第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
（4）第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。
上面是一方主动关闭，另一方被动关闭的情况，实际中还会出现同时发起主动关闭的情况，具体流程如下图：
流程和状态在上图中已经很明了了，在此不再赘述，可以参考前面的四次挥手解析步骤。
酋长从宫中回来不久，国王就颁布了新的TCP协议法案，这次修正版的TCP协议运行的很好，举国上下一片喜悦
经过上次的聊天后，司马和上官成为了好朋友，今天，司马又给上官发消息了，但是这次，两人建立连接后，同时给对方发送了一个报文“在吗？”,导致过了一会，司马和上官都收到对方的“在吗？”如下图：
在聊天完后，好学的司马又去请教酋长去了，酋长说，TCP是允许你们同时给对方发消息的，这种特性有一个专业名字叫做“全双工”，“哦，原来是这样”，“司马恍然大悟。原来TCP里面的门道挺多”，下来得好好学习学习,司马心中暗自说道
司马又找好哥们上官聊天了，与往常一样，建立连接，聊完天后，断开连接。这次司马特别有心，用了一个小本子记录下这次TCP断开连接的过程。
① 刚开始，司马发了一个“连接释放报文段”表示自己不再发送聊天消息了
② 然后上官接到这个“连接释放报文段”后给司马发出一个“确认报文段”，表示自己收到了
这时候，司马到上官方向的连接断了，即：司马没有消息给上官发了，但是上官到司马这个方向的连接还没有断，所以上官还可以给司马发送消息，他可能还有些话没说完。如下图：
③
1>上官这时候如果没有啥消息给司马发了，那他也会发送一个“连接释放报文段”给司马，表明他想断开连接（上官到司马方向的连接）
2>上官这时候如果还有消息想给司马发，那就按照往常一样把消息从他这边发给司马（因为从上官到司马这个方向的连接还没有断），等到发送完成后，然后再发送”连接释放报文段”
④ 司马收到这个报文后，也会给上官发送一个”确认报文段“以表明自己自己收到这个报文
⑤ 但是这个时候司马还不能撒手不管，他还需等待一段时间才可以进入到“CLOSED”（关闭）状态，表明自己的这次连接已经关闭了。可以接受下次连接了。
⑥ 当上官收司马的确认后，自己也进入“CLOSED”状态
完整的TCP四次挥手如下图：
司马下来看了看小本子，心中产生了一个疑惑，为什么我最后一次给上官发送确认，我还需要等一段时间，我不想等这么长时间，多麻烦。
他找酋长去诉苦去了，酋长说：“你等待这么长时间是有非常有必要的，你想啊，咱们TCP是不是规定了发出去的“请求报文(可能是请求连接，也有可能是请求关闭)”需要得到对方的确认,如果超过一定时间得不到确认会进行超时重传
如果说你给上官发送的那个确认如果在中途丢失了，上官迟迟等不到你的确认，他肯定会执行超时重传给你重新发一个请求关闭连接的报文的，如果你不等待这么长时间而直接进入关闭状态，是不是就接收不到这个重传的报文了？那上官是不是就收不到你的确认，进而上官就不能正常关闭了？如下图：
所以说，你在等的这段时间，其实是要确保你的确认让对方收到，如果对方超时重传一个连接释放报文段，这个时候你还没有关闭，那你就可以重新发一个确认给他呀”
“哦，原来是这样呀”，司马心中的怨气立马就消失了。
从此计算机帝国走向了互联网的时代
（1）三次握手是什么或者流程？四次握手呢？
自己往上翻~
（2）为什么建立连接是三次握手，而关闭连接却是四次挥手呢？
解释1、由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
解释2、这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。
注：参考来自以下，感谢
地址1：https://blog.csdn.net/Mark2When/article/details/54956559
地址2：https://blog.csdn.net/qq_30137611/article/details/77941313
标签：可靠 参考 ima prot 挥手 定时 超时重传 recv 还需要
原文地址：https://www.cnblogs.com/it-taosir/p/9912397.html
