HTTP小记

一、请求方法

方法名	含义
GET	请求资源
POST	传输实体主体，一般是向服务器发送内容时用
HEAD	获取报文首部，用于确认URI的有效性及资源更新时间等
OPTIONS	查询针对请求URI指定的资源支持的方法
CONNECT	要求在与代理服务器通信时建立隧道
TRACE	追踪路径，一般不用
PUT	向服务器传输文件，一般不用
DELETE	删除文件，一般不用

二、状态码

状态码	原因短语	解释
200	OK	服务器已成功处理请求
204	No Content	请求已成功处理，但在返回的响应报文中不含实体的主体内容
206	Partial Content	客户端进行了范围请求，服务器成功执行了这部分的请求
301	Moved Permanently	永久重定向，资源已经被分配了新的URI
302	Found	临时重定向
303	See Other	和302差不多
304	Not Nodified	客户端发送附带条件的请求时，没有满足条件的情况
307	Temporary Redirect	和302差不多
400	Bad Request	请求报文中存在语法错误
401	Unauthorized	登录认证
403	Forbidden	请求的资源被服务器拒绝了
404	Not Found	服务器上没有要请求的资源
500	Internal Server Error	内部服务器错误
503	Service Unavailable	服务器暂时处于超载或正在进行停机维护，现在无法处理请求

三、HTTP首部字段

每行后面都有一个回车（CR，Carriage Returen）和换行（LF，Line Feed）。

http首部字段有很多，这里只记录几个常用的，了解一下。

字段名	含义
Host	服务器地址
User-Agent	用户使用的浏览器
Accept	用户浏览器可以处理的媒体类型
Accept-Language	支持的语言
Accept-Encoding	支持的编码方式
Date	创建报文的日期
Content-Tpye	实体主体的媒体类型

四、抓包分析

以访问搜狐网站为例：

先ping一下搜狐网站，看一下搜狐的ip地址

 运行wireshark，浏览器输入www.sohu.com，回车，wireshark抓包：

可以看到浏览器和服务器的交互过程。

下面是三次握手：

四次挥手：

五、SSL/TLS

转载：https://blog.****.net/includeiostream123/article/details/51135349

SSL(Secure Socket Layer)，安全套接层

TLS(Transport Layer Secure)，安全传输层

引用：http://www.techug.com/post/https-ssl-tls.html

SSL是上世纪90年代中期，由网景公司设计的。（顺便插一句，网景公司不光发明了 SSL，还发明了很多 Web 的基础设施——比如“CSS 样式表”和“JS 脚本”）

为啥要发明 SSL 这个协议捏？因为原先互联网上使用的 HTTP 协议是明文的，存在很多缺点——比如传输内容会被偷窥（嗅探）和篡改。发明 SSL 协议，就是为了解决这些问题。

到了1999年，SSL因为应用广泛，已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化之后的名称改为 TLS（是“Transport Layer Security”的缩写），中文叫做“传输层安全协议”。
很多相关的文章都把这两者并列称呼（SSL/TLS），因为这两者可以视作同一个东西的不同阶段。

SSL只到SSL3.0，TLS1.0可以看成SSL3.1。

查看火狐浏览器所支持的SSL/TLS协议的版本：

引用：https://blog.****.net/includeiostream123/article/details/51135349

打开火狐浏览器，地址栏输入about:config，然后搜索tls.version，就可以看到：

其中security.tls.version.min和security.tls.version.max两项决定了Firefox支持的SSL/TLS版本，根据Firefox的介绍，这两项的可选值及其代表的协议是：

• 0 – SSL 3.0
• 1 – TLS 1.0
• 2 – TLS 1.1
• 3 – TLS 1.2
• 4 – TLS 1.3

HTTPS背后的加密算法：

当你在浏览器的地址栏上输入https开头的网址后，浏览器和服务器之间会在接下来的几百毫秒内进行大量的通信。InfoQ的这篇文章对此有非常详细的描述。这些复杂的步骤的第一步，就是浏览器与服务器之间协商一个在后续通信中使用的**算法。这个过程简单来说是这样的：

1. 浏览器把自身支持的一系列Cipher Suite（**算法套件，后文简称Cipher）[C1,C2,C3, …]发给服务器；
2. 服务器接收到浏览器的所有Cipher后，与自己支持的套件作对比，如果找到双方都支持的Cipher，则告知浏览器；

了解了SSL/TLS协议后，可以使用Wireshark（或类似的可以抓去网络包的工具）通过分析网络包的信息，来查看浏览器发送给服务器的所有Cipher。Wireshark是一款使用简单却非常强大的抓包工具。

浏览器会首先发起握手协议，既一个“ClientHello”消息，在消息体中，可以找到Firefox支持的Cipher。在Wireshark中，按照Protocol协议排序，然后从TLS 1.2协议的报文中找到一个Info为“Client Hello”的。选中这个，然后在下面的报文信息窗口中依次找到Secure Sockets Layer -> TLSv1.2 Record Layer -> Handshake Protocal -> Cipher Suites。例子中的第一个Cipher是：TLS_AES_128_GCM_SHA256 (0x1301)，一共有14个:

如果继续找一个Info为“ServerHello”的报文，可以在类似的位置找到服务器返回的Cipher，在本例中是TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f): 

那么Cipher的这一长串名字是什么含义呢？其实，每种Cipher的名字里包含了四部分信息，分别是

• **交换算法，用于决定客户端与服务器之间在握手的过程中如何认证，用到的算法包括RSA，Diffie-Hellman，ECDH，PSK等
• 加密算法，用于加密消息流，该名称后通常会带有两个数字，分别表示**的长度和初始向量的长度，比如DES 56/56, RC2 56/128, RC4 128/128, AES 128/128, AES 256/256
• 报文认证信息码（MAC）算法，用于创建报文摘要，确保消息的完整性（没有被篡改），算法包括MD5，SHA等。
• PRF（伪随机数函数），用于生成“master secret”。

　　完全搞懂上面的内容似乎还需要一本书的介绍（我已经力不从心了）。不过大致了解一下，有助于理解Cipher的名字，比如前面服务器发回给客户端的Cipher，

　　TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

　　从其名字可知，它是

• 基于TLS协议的；
• 使用ECDHE、RSA作为**交换算法；
• 加密算法是AES（**和初始向量的长度都是128）；
• MAC算法（这里就是哈希算法）是SHA。

　　熟悉了Cipher名字背后的含义后，让我们看看像IIS这样的Web服务器如何选择一个**算法呢？假如浏览器发来的**算法套件为[C1, C2, C3]，而Windows Server支持的套件为[C4, C2, C1, C3]时，C1和C2都是同时被双方支持的算法，IIS是优先返回C1，还是C2呢？答案是C2。IIS会遍历服务器的**算法套件，取出第一个C4，发现浏览器并不支持；接下来取第二个C2，这个被浏览器支持！于是，IIS选择了C2算法，并将它包含在一个“ServerHello”握手协议中，发回给客户端。