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

写在前面

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

本身的理解

三次握手:

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

四次挥手:

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

为何是三次握手不是更多后者是更少?
**假如次数是两次若是是客户端->服务端请求链接,服务端->客户端赞成链接,这样客户端直接发送数据,这样无非是最好的也最节约资源的.可是会出现如下的状况
**可是假如是两次,可是客户端->服务端发送请求链接的请求时,若是有由于网络的缘由致使请求在某一个节点滞留,一直延误到此次请求链接释放了以后才到达的服务端,服务端->客户端赞成链接,而且一直等待着客户端发送请求过来,可是对于客户端来讲根本就没有此次的请求,可是服务端的资源就这样一直白白的浪费在这里
** 若是使用的三次握手的话,服务端发出了赞成链接的确认以后,可是因为客户端一直没有给出确认的回复,那么服务端是不会建立链接的
** 由上面的解释咱们就知道两次不能完美的解决链接的问题,可是三次已经解决了,因此若是次数更多的话固然是能够完美解决建立链接的问题,可是这已是一种浪费了.

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

在断开链接的时候要等2MSL是为何?

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

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

各层做用请参见

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

2、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，这样关闭完成。

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

由于当Server端收到Client端的SYN链接请求报文后，能够直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。可是关闭链接时，当Server端收到FIN报文时，极可能并不会当即关闭 SOCKET，因此只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端全部的报文都发送完了，我才能发送FIN报文，所以不能一块儿发送。故须要四步握手。

二、为何客户端最后还要等待2MSL？

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

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

3、TCP和UDP的区别  

一、TCP面向链接（如打电话要先拨号创建链接）；UDP是无链接的，即发送数据以前不须要创建链接  

（链接和无链接）

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

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

（可靠和不可靠）

三、TCP面向字节流，其实是TCP把数据当作一连串无结构的字节流；UDP是面向报文的

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

（字节流和报文加拥塞）

四、每一条TCP链接只能是点到点的; UDP支持一对一，一对多，多对一和多对多的交互通讯

（一对一和一对多）

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

（开销问题）

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

简单再了解

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

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

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

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

五、支持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...