图解Http与Https

超、凢脫俗 2022-05-27 07:22 207阅读 0赞

# 一、TCP报文格式 #

![这里写图片描述][70]   
（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/IP协议族中一个重要协议：TCP协议，在传输层。 **  
特点：可靠性。通过连接管理（三握四挥），序列号，确认号，拥塞控制，重传控制来保证可靠性。   
头部长度：一般为20字节，选项最多40字节，限制60字节。

![这里写图片描述][SouthEast]

##### 逐个分析： #####

*  16位源端口号和16位目的端口号。
 *  32位序号：一次TCP通信过程中某一个传输方向上的字节流的每个字节的编号，通过这个来确认发送的数据有序，比如现在序列号为1000，发送了1000，下一个序列号就是2000。
 *  32位确认号：用来响应TCP报文段，给收到的TCP报文段的序号加1，三握时还要携带自己的序号。
 *  4位头部长度：标识该TCP头部有多少个4字节，共表示最长15\*4=60字节。同IP头部。
 *  6位保留。6位标志。URG（紧急指针是否有效）ACK（表示确认号是否有效）PSH（提示接收端应用程序应该立即从TCP接收缓冲区读走数据）RST（表示要求对方重新建立连接）SYN（表示请求建立一个连接）FIN（表示通知对方本端要关闭连接）
 *  16位窗口大小：TCP流量控制的一个手段，用来告诉对端TCP缓冲区还能容纳多少字节。
 *  16位校验和：由发送端填充，接收端对报文段执行CRC算法以检验TCP报文段在传输中是否损坏。
 *  16位紧急指针：一个正的偏移量，它和序号段的值相加表示最后一个紧急数据的下一字节的序号。

**IP头部信息：**   
头部长度：通常20字节，有选项时更长，总共不超过60字节。   
IP数据报长度：65535字节。

![这里写图片描述][SouthEast 1]

#### 逐个分析： ####

*  4位版本号：IP协议（IPv4）版本号位4
 *  4位头部长度：标识头部有多少个4字节，即最大共15\*4个字节
 *  8位服务类型：包含一个4位优先权字段：最小延时，最大吞吐量，最高可靠性和最小费用。
 *  16位总长度：表示整个IP数据报的长度，最大表示65535，但由于MTU限制，一般无法到达这个值。
 *  16位标识：唯一的标识数据报。系统采用加1的式边发送边赋值。
 *  3位标识（保留，DF禁止分片，MF更多分片）：所以这个标志是为分片存在，DF设置时禁止分片所以如果数据报太大则发送失败。MF设置时，如果产生分片，除了最后一个分片，其他此片置1。
 *  13位分片偏移：分片相对原始IP数据报开始处的偏移。
 *  8位生存时间（TTL）：数据报到达目的地之前允许经过的路由跳跳数。跳一下减1，得0丢弃。
 *  8位协议：用来区分上层协议（ICMP为1，TCP为6，UDP为17）。
 *  16位头部校验和：仅以CRC算法检验数据报头部在传输过程中是否损坏。
 *  32位源端口IP地址和目的端口地址很明白。
 *  选项（可变长）：记录路由，告诉途径得所有路由把IP填进来。 时间戳，告诉每个路由器都将数据报被转发的时间传进来。松散路由选择，指定一个路由器IP地址列表，必须按这个表发送，严格路由选择，数据报经过路由表。

# 二、三次握手 #

三次握手（Three-Way Handshake）即建立TCP连接，就是指建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立。在socket编程中，这一过程由客户端执行connect来触发，整个流程如下图所示：

**       ![20180413192031277][]**

![这里写图片描述][70 1]

（1）第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN\_SENT状态，等待Server确认。   
（2）第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=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之间可以开始传输数据了。

SYN攻击：   
在三次握手过程中，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

*  1

--------------------

# 三、四次挥手 #

四次挥手（Four-Way Wavehand）即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发。

## 1. 一方将执行主动关闭，而另一方则执行被动关闭 ##

由于TCP连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭：整个流程如下图所示：

![20180413192055786][]

![这里写图片描述][70 2]

（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状态，完成四次挥手。

## 2.同时发起主动关闭 ##

具体流程如下图：   
![这里写图片描述][70 3]

--------------------

# 四、注意 #

为什么建立连接是三次握手，而关闭连接却是四次挥手呢？

这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。

**五、https通信机制**

**![20180413193427654][]**

图中简述了HTTPS的通信步骤，具体分为以下：  
1，客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的制定版本、加密组件列表(加密算法，密钥长度等)；  
2，服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的；  
3，之后服务器发送Certificate报文。报文中包含公开密钥证书；  
4，最后服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束；  
5，SSL第一次握手结束之后，客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称之为Pre-master secret的随机密码串。该报文已经用步骤3中的公开密钥进行加密；  
6，接着客户端继续发送Change Cipher Spec报文。该报文会提示服务器，在此报文之后的通信会采用Pre-master secret密钥加密；  
7，客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准；  
8，服务器同样发送Change Cipher Spec报文；  
9，服务器同样发送Finished报文；  
10，服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。当然，通信会收到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP请求；  
11，应用层协议通信，即发送HTTP响应；  
12，最后由客户端断开连接。断开连接时，发送close\_notify报文。这步之后再发送TCP FIN报文来关闭与TCP的通信。

下图是从仅使用服务器端的公开密钥证书(服务器证书)建立HTTPS通信的整个过程的图解。

![20180413193658256][]

HTTPS也存在一些问题：  
问题一，即当使用SSL时，它的处理速度会变慢。SSL的慢分两种。一种是通信慢，另一种是指由于大量消耗CPU及内存等资源，导致处理速度变慢。和使用HTTP相比，网络负载可能会变慢2到100倍。  
问题二，SSL必须进行加密处理。在服务器和客户端都需要进行加密和解密的运算处理，这样会比HTTP更多地消耗服务器和客户端的硬件资源，导致负载增强。

因此，虽然HTTPS安全可靠，但是不是所有的Web网站都要一直使用HTTPS。

**六、https与http对比**

超文本传输协议HTTP协议被用于在Web浏览器和网站服务器之间传递信息，HTTP协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。

为了解决HTTP协议的这一缺陷，需要使用另一种协议：安全套接字层超文本传输协议HTTPS，为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL协议，SSL依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。

一、HTTP和HTTPS的基本概念

HTTP：是互联网上应用最为广泛的一种网络协议，是一个客户端和服务器端请求和应答的标准（TCP），用于从WWW服务器传输超文本到本地浏览器的传输协议，它可以使浏览器更加高效，使网络传输减少。

HTTPS：是以安全为目标的HTTP通道，简单讲是HTTP的安全版，即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。

HTTPS协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。

二、HTTP与HTTPS有什么区别？

HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全，为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。简单来说，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。

HTTPS和HTTP的区别主要如下：

1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。

2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。

3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

三、HTTPS的工作原理

我们都知道HTTPS能够加密信息，以免敏感信息被第三方获取，所以很多银行网站或电子邮箱等等安全级别较高的服务都会采用HTTPS协议。

![HTTP与HTTPS的区别-马海祥博客][HTTP_HTTPS_-]

客户端在使用HTTPS方式与Web服务器通信时有以下几个步骤，如图所示。

（1）客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。

（2）Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。

（3）客户端的浏览器与Web服务器开始协商SSL连接的安全等级，也就是信息加密的等级。

（4）客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。

（5）Web服务器利用自己的私钥解密出会话密钥。

（6）Web服务器利用会话密钥加密与客户端之间的通信。

![2012071410212142.gif][]

四、HTTPS的优点

尽管HTTPS并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但HTTPS仍是现行架构下最安全的解决方案，主要有以下几个好处：

（1）使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；

（2）HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。

（3）HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。

（4）谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”。

五、HTTPS的缺点

虽然说HTTPS有很大的优势，但其相对来说，还是存在不足之处的：

（1）HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；

（2）HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；

（3）SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。

（4）SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。

（5）HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。

六、http切换到HTTPS

如果需要将网站从http切换到https到底该如何实现呢？

这里需要将页面中所有的链接，例如js，css，图片等等链接都由http改为https。例如：http://www.baidu.com改为https://www.baidu.com

BTW，这里虽然将http切换为了https，还是建议保留http。所以我们在切换的时候可以做http和https的兼容，具体实现方式是，去掉页面链接中的http头部，这样可以自动匹配http头和https头。例如：将http://www.baidu.com改为//www.baidu.com。然后当用户从http的入口进入访问页面时，页面就是http，如果用户是从https的入口进入访问页面，页面即使https的。

**转载链接:  https://blog.csdn.net/lulu950817/article/details/79933104**

**转载链接：https://www.jianshu.com/p/f1f3538b3798**

**转载链接: https://www.cnblogs.com/wqhwe/p/5407468.html**

[70]: /images/20220527/3bf12350a9a34efdbce60c9f90d3cf26.png
[SouthEast]: /images/20220527/251ac0a32c294c74b681b974a01c30a8.png
[SouthEast 1]: /images/20220527/607f2876381b4977a606e9c27699035c.png
[20180413192031277]: /images/20220527/c4217eebcecd4b7c9e389d4847ee1876.png
[70 1]: /images/20220527/6e3688c29d52413d88e1dfbaa9442f72.png
[20180413192055786]: /images/20220527/21b8d1a2598e46cb897a88976e6a83b5.png
[70 2]: /images/20220527/9e389001ea73444da805b818a01e271d.png
[70 3]: /images/20220527/2a4461b0716a4ed49b603c997a522f16.png
[20180413193427654]: /images/20220527/f5916b95ce584f7cb000d8211d314644.png
[20180413193658256]: /images/20220527/c5e3ec386c4642a18648c455035f7eef.png
[HTTP_HTTPS_-]: /images/20220527/495c2f0b87d44dddb779e436a990d48d.png
[2012071410212142.gif]: /images/20220527/e27891165aa84115b409099b92e1ef47.png