消息格式

HTTP请求消息

• 第一行称为请求行,通过本行可了解请求的内容(具体参数解释见下文)
• 第二部分是消息头,每行包含一个请求字段,表示请求的附加信息,行数根据具体情况可变
• 消息头跟消息体中间有一个空行隔开,方便区分不同部分信息
• 消息体包含客户端向服务器发送的数据,例如POST方法向Web服务器发送的页面表单数据

例子:

请求行参数解析

方法部分

方法部分可以使用的参数如下:

• GET 获取URI指定的信息,比如如果请求的是文件则返回文件内容.
• POST 从客户端向服务端发送数据,一般用于表达中的数据
• HEAD 同GET,只是他返回的是HTTP的消息头,并不返回数据内容,可以用于获取文件的最后更新时间等信息
• OPTIONS 查询HTTP服务器端支持的HTTP方法种类,比如服务器支持GET,POST的话,就返回GET\POST.
• PUT 用来传输文件,在消息体中包含文件内容,保存到请求行URI指定的位置
• DELETE 删除URI指定位置的资源
• TRACE 让WEB服务器将之前的请求通信返回给客户端.客户端通过TRACE查询自己发送出去的请求是怎么样在发送过程中被加工修改的,可以用来确定连接过程中发生的一系列操作.
• CONNECT 使用代理传输加密消息使用,主要使用SSL/TLS加密通信内容后经网络隧道传输.

URI

URI: 请求资源定位符 HTTP使用URI定位互联网上的资源.

客户端发送访问资源请求时候,例如访问"www.baidu.com "的时候,URI就可以是https://www.baidu.com/

HTTP版本

HTTP/1.0 1996年5月发布

HTTP/1.1 主流的版本

消息头

一连串的键值对,包含了客户端和服务器需要的一些信息.

HTTP响应消息

实例

• 状态行包括HTTP版本,状态码和响应短语
• 其余同上

状态行

• HTTP版本同上

状态码

1XX

不常用

2XX

• 200 OK

表示请求被服务器正常处理了.

• 204 Not Content

服务器已经成功处理请求,但是没有资源可以返回.

一般在客户端向服务器发消息,而服务器不需要对客户端发送新信息内容的情况下使用.

接受到这个状态码,浏览器显示的页面不进行更新.

• 206 Partial Content

客户端请求的是一部分信息,服务器成功返回了这部分

3XX

• 301 Moved Permanently

永久性重定向,表示请求的资源已经分配了新的URI,以后应使用资源现在对应的URI.

如果已经把之前的URI保存为书签了,那么应该更新书签.

• 302 Found

临时性重定向,表示资源已经被分配到新的URI,希望用户本次能使用新的URI访问.

已经移动的资源对应的URI将来可能依旧发生改变.

• 303 See other

表示请求对应的资源存在着另一个URI,服务器要求客户端应该使用GET方法定向请求的资源

与302的区别在于,303要求使用GET进行获取资源.

• 304 Not Modified

请求未满足服务器允许访问这个资源的条件

4XX

• 400 Bad Request

请求报文存在语法错误,需要修改请求的内容后再次发送请求.

• 401 Unauthorization

表示发送的请求需要进行HTTP认证的认证信息

• 403 Forbidden

表示请求资源的访问被服务器拒绝了,可能因为没有获得文件系统的访问授权,访问权限出现某些问题等

• 404 Not Found

最熟悉的!

服务器没有请求的资源.

表明服务器无法找到请求的资源

5XX

• 500 Internel Server Error

服务器在执行请求时候发生了错误

• 503 Service Unavilable

服务器超负载或者停机维护.

HTTP是无状态的

HTTP是无状态协议,HTTP自身不对请求和相应之间的通信进行保存.

也就是说,在HTTP这个级别,协议对于发送过的请求和响应都不做持久化处理.

优点是可以让HTTP协议简单,可以快速处理大量事务.

缺点是无状态可能导致业务变得棘手.

例如: 跳转网站之后,可能自己的登录状态就没有了,又需要重新登录

引入Cookie

HTTP/1.1虽然是无状态的,但是为了实现期望的保持状态功能,引入了Cookie.

Cookie是通过在请求和响应报文中写入Cookie信息来控制客户端的状态.

• Cookie会根据从服务器发来的响应报文内的一个叫做Set-Cookie的首部字段信息,通知客户端保存Cookie.
• 当下次客户端访问该服务器的时候,客户端自动在请求报文中加入Cookie之后发出去.
• 服务器检查客户端发来的Cookie,检查哪一个客户端发来的连接请求,再对比服务器的记录,最后得到之前的状态信息.

HTTP的连接

三次握手

• 客户端–发送带有 SYN 标志的数据包–一次握手–服务端
• 服务端–发送带有 SYN/ACK 标志的数据包–二次握手–客户端
• 客户端–发送带有带有 ACK 标志的数据包–三次握手–服务端

为什么要三次握手?

三次握手的目的是建立可靠的通信信道,三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

• 第一次握手：

Client 什么都不能确认； Server 确认了对方发送正常，自己接收正常

• 第二次握手：

Client 确认了：自己发送、接收正常，对方发送、接收正常； Server 确认了：对方发送正常，自己接收正常

• 第三次握手：

Client 确认了：自己发送、接收正常，对方发送、接收正常； Server 确认了：自己发送、接收正常，对方发送、接收正常

所以三次握手就能确认双发收发功能都正常，缺一不可。

推荐阅读:blog.csdn.net/qzcsu/artic…

四次挥手

• 客户端-发送一个 FIN，用来关闭客户端到服务器的数据传送
• 服务器-收到这个 FIN，它发回一 个 ACK，确认序号为收到的序号加1 。和 SYN 一样，一个 FIN 将占用一个序号
• 服务器-关闭与客户端的连接，发送一个FIN给客户端
• 客户端-发回 ACK 报文确认，并将确认序号设置为收到序号加1

任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。

举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。

与HTTP服务的Web服务器

用单台虚拟主机实现多个域名

HTTP/1.1规范允许一个服务器搭建多个 Web 站点，这是虚拟主机（Virtual Host，又称虚拟服务器）功能。

如果一台服务器内托管了两个域名，对应的同一个服务器 IP，当收到请求时就需要弄清楚究竟要访问哪个域名，由于虚拟主机可以寄存多个不同主机名和域名的 Web 网站，因此在发送 HTTP 请求时，必须在 Host 首部内完整指定主机名或域名的 URI。

通信数据转发程序 ：代理、网关、隧道

这些应用程序和服务器可以将请求转发给通信线路上的下一站服务器，并且能接收从那台服务器发送的响应再转发给客户端。

代理

代理： 接收客户端发送的请求后转发给其他服务器。代理不改变请求 URI，会直接发送给前方持有资源的目标服务器。

作用

缓存代理：预先将资源缓存保存在代理服务器上，当代理再次接收到对相同资源的请求时，就可以直接将之前缓存的资源作为响应返回。

透明代理：转发请求或响应时，不对报文做任何加工被称为透明代理，对报文内容进行加工的称为非透明代理。

网关

转发其他服务器通信数据的服务器，接收从客户端发送来的请求时，它就像自己拥有资源的源服务器一样对请求进行处理。

可以利用网关将HTTP请求转换成非HTTP请求.

网关能提高通信的安全性，因为可以在客户端与网关之间的通信线路上加密以确保连接的安全。

隧道

隧道： 按要求建立起一条与其他服务器的通信线路，届时使用 SSL 等加密手段进行通信，在通信双方断开连接时结束。隧道的目的是确保客户端能与服务器进行安全的通信。

保存资源的缓存

缓存是指代理服务器或客户端本地保存的资源副本，是代理服务器的一种。

优势在于避免多次从源服务器转发资源，客户端可就近从缓存服务器上获取资源，而源服务器也不必多次处理相同请求。

客户端的缓存： 浏览器缓存如果有效，不必再向服务器请求，而直接从本地读取。当判定缓存过期后，会向源服务器确认资源的有效性。若判断浏览器缓存失效，浏览器会再次请求新资源。

HTTPS

把添加了加密及认证机制的 HTTP 称为 HTTPS（HTTP Secure）。HTTPS 并非是应用层的一种新协议，只是 HTTP 通信接口部分用 SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协议代替而已。SSL 是独立于 HTTP 的协议，所以其他运行在应用层的 SMTP 和 Telnet 等协议均可配合 SSL 协议使用。

HTTP的缺点

• 通信使用明文,内容可能被窃听

• 不验证通信方的身份,因此有可能遭到伪装

• 无法验证报文的完整性,有可能内容被篡改

加密

对称加密

加密时候使用密钥,共享加密是将此密钥发送给对方. 两者使用同一个密钥进行加密解密.

但是缺点在于,当在互联网上发送密钥时候,通信被监听了(参考上一节第一点,"通信使用明文,内容可能被窃听 "),那么监听者也可以获得密钥,这个时候当通信的一方将数据加密后在网络传输的时候,监听者窃取到密文他可以用之前监听到的密钥进行解密,则加密失败!

非对称加密

加密时候使用两把钥匙,一把称为私有密钥,一把称为公开密钥.

这种方式相比对称加密更为复杂,效率低.

私有密钥是不能让任何人知道的,公开的则无所谓.

公钥加密的数据,可以用私钥解开;私钥加密的数据,可以用公钥解开.

HTTPS是如何加密的?

分析对称加密和非对称加密:

既然对称加密密钥可能在发送传播阶段被窃取,导致加密失败,那么对称加密发送公开密钥的时候,依然可能被窃取,那么该如何做呢?

• 浏览器第一次访问的时候,服务器把自己的公钥A发过来
• 浏览器随机生成一个密钥B,使用服务器的公钥A进行加密
• 然后将加密后的随机生成的密钥发送给服务器
• 服务器使用自己的私钥A对其进行解密,得到浏览器生成的密钥B (在此使用的是非对称加密)
• 在这个过程里面,因为浏览器使用服务器的公钥加密后,只有服务器的私钥可以解开,所以结算有人窃听到了加密后密钥的内容,因为没有服务器的私钥,所以无法解开
• 至此,客户端跟服务器都有了一把相同的密钥B,且这个密钥是别人无法知道的,就可以使用密钥B可以进行安全的对称加密通信了.

但是此时又有了一个问题:如果在服务器给客户端发送公钥A的时候,恶意程序替换了信息(上文第三点,"无法验证报文的完整性,有可能内容被篡改")

那么当窃听者得到客户端发送的"加密后的密钥B"的时候,就可以解密其得到客户端的密钥B.

如何解决?

请CA机构帮忙!(juejin.cn/post/692529…) CA 机构专门用于给各个网站签发数字证书，从而保证浏览器可以安全地获得各个网站的公钥。

• 首先，我们作为一个网站的管理员需要向 CA 机构进行申请，将自己的公钥提交给 CA 机构。CA 机构则会使用我们提交的公钥，再加上一系列其他的信息，如网站域名、有效时长等，来制作证书。

• 证书制作完成后，CA 机构会使用自己的私钥对其加密，并将加密后的数据返回给我们，我们只需要将获得的加密数据配置到网站服务器上即可。

• 然后，每当有浏览器请求我们的网站时，首先会将这段加密数据返回给浏览器，此时浏览器会用 CA 机构的公钥来对这段数据解密。

• 如果能解密成功，就可以得到 CA 机构给我们网站颁发的证书了，其中当然也包括了我们网站的公钥。

So?

综上可以得到,HTTPS使用的是对称密钥和非对称密钥结合的形式.

• 交换密钥的时候使用对非对称钥加密方式
• 在其后建立连接后进行交换报文的时候,就可以使用对称密钥了.
• 兼顾安全(交换密钥阶段)与效率(交换报文阶段),因为对称密钥效率高.

参考

图解HTTP

网络是怎么连接的

图解TCP/IP

juejin.cn/post/692529… HTTPS加密

snailclimb.gitee.io/javaguide/#… 计算机网络面试指导