Http协议再理解（一）经典模型、三次握手、四次挥手 DannyCloud

写在前面

原本是自己整理的,但是发现还是原博主写的比较的全面,在这里附上原文章地址,同时贴出来方便日后自己查阅学习.
原文章地址

自己的理解

三次握手:

• 客户端->服务端: 我要准备连接你了
• 服务端->客户端: 好的我知道了 + 这是我专门给你的特殊标记
• 客户端->服务端: 我收到你的特殊标记了
• (服务端收到客户端的确认,此时就已经成功的建立连接了)

四次挥手:

• 客户端->服务端: 我数据全部发送完了
• 服务端->客户端: 我知道了,但是我还是会向你发送后面的数据的(如果服务端还有数据发到客户端,客户端还是会继续接收数据的)
• 服务端->客户端: 我的所有数据也发送完了
• 客户端->服务端: 我知道了(我等待2MSL之后我就会关闭连接了),你可以关闭连接了
• (服务端收到客户端的确认之后就会断开连接)

为什么是三次握手不是更多后者是更少?
**假如次数是两次如果是客户端->服务端请求连接,服务端->客户端同意连接,这样客户端直接发送数据,这样无非是最好的也最节约资源的.但是会出现以下的情况
**但是假如是两次,但是客户端->服务端发送请求连接的请求时,如果有因为网络的原因导致请求在某一个节点滞留,一直延误到这次请求连接释放了之后才到达的服务端,服务端->客户端同意连接,并且一直等待着客户端发送请求过来,但是对于客户端来说根本就没有这次的请求,但是服务端的资源就这样一直白白的浪费在这里
** 如果使用的三次握手的话,服务端发出了同意连接的确认之后,但是由于客户端一直没有给出确认的回复,那么服务端是不会创建连接的
** 由上面的解释我们就知道两次不能完美的解决连接的问题,但是三次已经解决了,所以如果次数更多的话当然是可以完美解决创建连接的问题,但是这已经是一种浪费了.

为什么挥手是四次?
因为TCP是全双工的数据传输服务(数据可以在两个方向上传输)就算此时(1)客户端->服务端,我已经发送完请求的数据了,(2)服务端->客户端,我知道了,但是此时收到确认的客户端并不会执行关闭连接的操作,因为就算此时客户端已经不会在发送请求的数据了,但是这个时候服务端还是会向客户端发送相应的数据,只有当(3)服务端->客户端,我所有相应的数据也已经发送完毕了,收到确认的(4)客户端->服务端,我知道你没有数据给我了,再等待2MSL之后客户端关闭连接,而此时收到确认的服务端就会关闭连接了

在断开连接的时候要等2MSL是为什么?

• 是为了保证客户端发送的最后一次的确认可以到达服务端(因为这次确认有可能会丢失),对于服务端来说在服务端->客户端,我已经没有相应的数据给你了之后,如果没有收到服务端的确认们就会一直的发送这个确认,延时2MSL是为了可以在这个时间内收到服务端的重传,接着给出回应,在重新计时
• 当出现这2MSL时其实客户端已经确认了知道服务端没有数据在传输过来了,准备关闭连接了,那在这个世间内可以清除所有本次连接内所产生的报文段,这样新的请求不会出现在旧的请求报文中

一、网络协议分层--经典五层模型

各层作用请参见

• 物理层：定义物理设备之间如何传输数据
• 数据链路层：在通信的实体间建立数据链路链接
• 网络层：为数据在节点之间的传输创建逻辑链路
• 传输层：向用户提供可靠的端到端的服务，传输层通过封装向高层屏蔽了下层数据通信的细节
• 应用层：为应用软件提供了很多服务，构建于tcp协议之上，屏蔽了网络传输相关的细节

二、Http三次握手和四次挥手

前置：

• Http请求是基于Tcp connection这个链接的

• 位码即tcp标志位,有6种标示:

  • SYN(synchronous建立联机) 、
  • ACK(acknowledgement 确认)、
  • PSH(push传送)FIN(finish结束)、
  • RST(reset重置)、
  • URG(urgent紧急)
  • Sequence number(顺序号码) 
  • Acknowledge number(确认号码)

（一）三次握手：

• 第一次握手：主机A发送位码为syn＝1,随机产生seq number=1234567的数据包到服务器，主机B由SYN=1知道，A要求建立联机；
• 第二次握手：主机B收到请求后要确认联机信息，向A发送ack number=(主机A的seq+1),syn=1,ack=1,随机产生seq=7654321的包；
• 第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，主机A会再发送ack number=(主机B的seq+1),ack=1，主机B收到后确认seq值与ack=1则连接建立成功。

注：为什么要采用三次握手，两次不行吗？

（二）四次挥手：

• 第一次挥手：TCP发送一个FIN(结束)，用来关闭客户到服务端的连接。
• 第二次挥手：服务端收到这个FIN，他发回一个ACK(确认)，确认收到序号为收到序号+1，和SYN一样，一个FIN将占用一个序号。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。（服务器端继续发送未发送完的数据）
• 第三次挥手：服务端发送一个FIN(结束)到客户端，服务端关闭客户端的连接。
• 第四次挥手：客户端发送ACK(确认)报文确认，并将确认的序号+1，这样关闭完成。

注：1、那么为什么是4次挥手呢？tcp握手的时候为何ACK(确认)和SYN(建立连接)是一起发送。挥手的时候为什么是分开的时候发送呢？

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

2、为什么客户端最后还要等待2MSL？

第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。

第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

三、TCP和UDP的区别  

1、TCP面向连接（如打电话要先拨号建立连接）；UDP是无连接的，即发送数据之前不需要建立连接  

（连接和无连接）

2、TCP提供可靠的服务。即通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;

     UDP尽最大努力交付，即不保证可靠交付

（可靠和不可靠）

3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流；UDP是面向报文的

    UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）

（字节流和报文加拥塞）

4、每一条TCP连接只能是点到点的; UDP支持一对一，一对多，多对一和多对多的交互通信

（一对一和一对多）

5、TCP首部开销20字节;UDP的首部开销小，只有8个字节

（开销问题）

6、TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道

简单再了解

1、简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。

2、灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。

3.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。

4.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

5、支持B/S及C/S模式。

参考：http://www.cnblogs.com/ranyon...

          https://www.cnblogs.com/qdhxh...

         https://blog.csdn.net/qq_18425655/article/details/52163228

         https://blog.csdn.net/qzcsu/a...

        https://blog.csdn.net/yanxinr...