一、请求方法
| 方法名 | 含义 |
| 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.csdn.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.csdn.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的这篇文章对此有非常详细的描述。这些复杂的步骤的第一步，就是浏览器与服务器之间协商一个在后续通信中使用的密钥算法。这个过程简单来说是这样的：
- 浏览器把自身支持的一系列Cipher Suite（密钥算法套件，后文简称Cipher）[C1,C2,C3, …]发给服务器；
- 服务器接收到浏览器的所有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”握手协议中，发回给客户端。