一文了解HTTP协议
如果想要在专业技术道路上走得更坚实，绝对不能绕开HTTP协议的学习；
对基础和核心部分的深入学习，是成为一名专业技术人员的前提，以不变应万变才是立足之本；
有些细节无法通过查阅资料立即领悟到，还得靠扎实的基础和平日的积累；
不感兴趣的领域我不清楚，但我擅长的领域就放心交给我吧；
HTTP的诞生
web的目的是共享知识，它涉及：超文本标记语言、统一资源定位符和传输文档内容的协议HTTP，分别对应知识的表示、知识的定位和知识的传输；
如何探测到通信目标、由哪一端发起通信、使用什么语言进行通信、如何终止通信等规则都需要事先确定；在不同硬件、操作系统之间的通信需要一种规则，这种规则就是协议；
HTTP1.0因为存在模糊不清的地方很快被废弃，目前主流HTTP协议版本是1.1；
相关协议
TCP/IP协议族最主要的特点就是分层；包括应用层、传输层、网络层、数据链路层；其中应用层负责产生和消费信息、传输层负责点到点的信息传输、网络层负责路由规划、数据链路层负责信息的在物理介质上的传递；
传输层对来自应用层的信息进行分割，并打上标记序号以及ip、端口号后交给网络层；网络层根据ip添加对应的MAC地址信息后交给数据链路层；
信息在发送端，每经过一层就会添加上一层该层特有的首部信息，在接收端解析消息时每经过一层，就会把对应的首部信息移除，这种把信息包装起来的方法称为封装；
IP协议是把数据包传送给对方，依赖两个地址：IP地址和MAC地址；IP地址指明节点被分配的地址，MAC地址指明节点固有地址；IP地址到MAC地址之间使用ARP协议进行转换；
TCP三次握手：发起端发送SIN报文A；接收端确认并回复SIN报文B；发送端再次对B报文进行确认；
TCP四次挥手：发起端发送FIN报文A；接收端确认FIN报文；接收端发送FIN报文，发起端回复FIN报文；
DNS提供从域名到IP以及从IP到域名的转换服务；ARP提供从IP地址到MAC地址的转换；
HTTP协议
URI，统一资源定位符，是某个协议表示的资源的定位标记符；由协议名称、登录信息、服务器地址、端口号、资源路径、查询字符串和片段标记符组成，如：
http://user:password@www.nilxuan.cn:8888/pdf/java/On-Java?page=12#cdsg
HTTP请求报文结构：
MethodName URI 协议/版本号
请求首部信息（key: value对）
(空行)
请求体（内容实体）
HTTP响应报文结构：
协议/版本号 状态码 原因短语
响应首部（key: value对）
(空行)
响应体（内容实体）
HTTP在协议层面不支持通信状态的保存；后面通过引入Cookie字段技术实现状态保持功能；
方法名是区分大小写的哦
| 方法名 | 作用 |
|---|---|
| GET | 获取uri指定的资源 |
| POST | 向uri指定的位置传输资源； |
| PUT | 本用于传输文件，在REST架构风格中用以更新实体 |
| HEAD | 获取uri指定资源的相关首部信息，以确认有效性、更新日期等情况 |
| DELETE | 本用于删除文件，在REST架构风格中用以删除实体 |
| OPTIONS | 获取uri指定资源所支持的请求方法，通过Allow响应首部返回 |
| TRACE | 追踪链路，在Max-Forwards首部设置数值，请求每经过一个服务器端就将其减一，等于0的时候就停止传输，返回200；用以确认发送的请求如何被修改； |
| CONNECT | 要求与代理服务器通信时建立素材，实现用隧道协议进行TCP通信，如SSL(Secure Socke Layer，安全套接字)和TLS(Transport Layer Security)等协议； |
HTTP协议为了避免TCP连接在一次请求-响应结束后立即断开，使用Keep-alive进行持久连接；所谓持久连接就是只要任意一端没有明确提出断开连接，则保持TCP连接状态；HTTP1.1中默认连接都是持久化的；
持久化连接使得以管道化方式发送多个http请求成为可能，这进一步提高了http响应速度；请求数越多，时间差就越明显；
HTTP协议属于无状态协议，所谓无状态协议是指协议本身没有规定以怎样的方式管理通信状态；HTTP使用Cookie技术管理客户端状态，即服务端在向客户端发送响应报文时，将Cookie信息写入Set-Cookie首部，客户端保存此Cookie并在下次请求时在Cookie首部携带该信息；
Cookie的信息包括：path：适用路径、expire：过期时间、sid：sessionId；
HTTP首部
HTTP分为四类：请求首部、响应首部、通用首部和实体首部；通用首部是指既能在请求报文中使用也能在响应报文中使用；实体首部是指请求或者响应报文中用于描述和实体内容相关信息的请求头，比如实体的编码、字符集、长度等；
报文结构：
请求报文结构：
响应报文结构：
通用首部字段：
请求首部字段：
实体首部字段：
响应首部字段：
报文主体通常等于实体主体；但是实体主体信息可以被压缩，此时报文实体指压缩后的信息；即报文主体是从传输内容的角度定义；实体主体是在传输信息的角度所定义；
常见的压缩算法有：gzip(GNU zip)、deflate(zlib)、compress(unix系统的标准压缩)、identity(不压缩)
提升传输速率：一是从传输方式来看，如使用持久连接和管道化技术；二是从传输内容上来看，可以对内容进行压缩（考虑压缩-解压缩带来的时间消耗和网络传输节约的时间消耗）
分块传输或许能提高页面的响应速度；HTTP1.1支持Transfer-Coding的机制，按某种编码方式传输；
MIME：multipurpose internet mail extentions，多用途因特网邮件扩展；在MIME中使用一种多部分对象集合（Multipart）的方法来容纳多份不同类型的数据；multipart/form-date；multipart/byterange——多个范围的内容；
内容协商机制是指HTTP client通过设置请求头中Accept、Accept-Charset、Accept-Encoding、Accept-Language等字段指示服务端尽可能返回满足条件的内容；它分为：服务端驱动协商&客户端驱动协商和透明协商；
- 服务端驱动协商：服务端根据请求头中内容，返回合适的内容；
- 客户端驱动协商：客户端支持用户手动选择或者通过JavaScript等方法决定要显示的内容并向服务端直接请求；
- 透明协商：服务端&客户端共同进行内容协商；【具体方式还不明确】
由于同一IP可能对应多个域名，所以在发送HTTP请求时必须携带Host请求参数以指明希望访问的域名；
HTTP状态码
HTTP状态码的作用就是向客户端描述返回的结果；
| 系列 | 状态码 | 状态描述 | 描述 |
|---|---|---|---|
| 2xx | |||
| 表示请求被正常处理 | 200 | OK | 请求被服务端正常处理 |
| 204 | No Content | 请求正常处理，但是响应报文不含实体主体 | |
| 206 | Partial Content | 客户端的范围请求被正常处理，响应报文包含由Content-Range指定范围的实体内容 | |
| 3xx | |||
| 表明浏览器需要执行某些特殊的动作； | 301 | Moved Permanently | 永久性重定向，按Location响应首部重新请求 |
| 302 | Found | 临时性重定向 | |
| 303 | See Other | 请求资源存在着另一个url，请使用get方法重新请求；这里301和302是按原有方法继续请求新的url，不过一般实现时可能会直接替换为GET | |
| 304 | Not Modified | 资源不满足客户端请求中设置的条件 | |
| 307 | Temporary Redirect | 临时重定向，与302同义，307保证不更换请求方法 | |
| 4xx | |||
| 客户端的请求存在错误，无法被处理 | 400 | Bad Request | 客户端请求存在语法错误 |
| 401 | Unauthorized | 请求未携带认证信息 | |
| 403 | Forbidden | 请求被服务器拒绝 | |
| 404 | Not Found | 资源不存在 | |
| 5xx | 500 | Internel Server Error | 服务端处理请求时发生了错误 |
| 503 | Service Unavailable | 服务器暂时处于超负载状态，无法进行响应；最后携带Retry-After首部指明可能恢复服务的时间 |
HTTPS
HTTP协议的不足：
- 通信信息明文，内容可能被窃听；
- 对通信方身份不做验证，可能会遇到伪装；
- 对报文不做完整性校验，内容可能被篡改；
可以对通信内容进行加密（防止窃听，但是仍然可能被篡改）或者对通信方式加密（使用HTTPS）
HTTP（HTTP Secure）=HTTP+加密+认证+完整性保护；Http可以认为是加了SSL（security socket layer）或者TLS（Transport Layer Security）的HTTP协议；
HTTP-SSL-TCP；SSL是独立于HTTP协议的协议，其他应用层协议SMTP、Telnet也可以使用SSL，可以认为SSL是世界上应用最为广泛的网络安全技术；
SSL采用了一种公开秘钥加密（Public-Key cryptography）的加密处理技术；
加密涉及到加密算法和加密秘钥，一般加密算法是公开的，密钥是保密的；加密的同时还需要解密，解密和加密均需要秘钥；加密和解密使用同一秘钥的方式称为共享秘钥加密（Common key crypto system），也叫对称秘钥加密；
HTTP中使用共享秘钥的一个难题是如何安全地交付秘钥？如果也使用HTTP协议，那么秘钥也有可能被窃听，同时也就失去了加密的意义；
公开密钥加密算法在加密和解密时使用不同的秘钥，其中公钥（用以加密）可以公开传播，私钥（用以解密）不能公开传播；
在使用公开秘钥加密算法进行加密时，发送密文的一方使用对方的公钥进行加密，对方接收到消息后再使用自己的私钥进行解密；
公开秘钥加密算法中通过公钥和密文很难得到明文；但是与共享秘钥加密相比，公开秘钥加密的速度非常慢；
回到HTTPS，它采用的是共享秘钥加密和公开秘钥加密两者的混合加密机制；在交换秘钥阶段使用公开秘钥加密，之后的建立通信并交换报文的阶段则使用共享秘钥加密；
所以问题就变成了如何验证公钥的正确性；如果伪装者给消息发送者提供了假的公钥（此时伪装者持有该公钥配对的私钥），那么伪装者获取到密文后就可以解密（信息此时被窃听），之后再用接收者的公钥重新加密后发送给接收者（此时信息被篡改），仍然无法达到安全通信的目的；其根本原因是未能实现通信双方身份的认证；
为了解决该问题，CA（Certificate Authority）出现了，即数字证书认证机构；由该机构颁发公钥证书；而该机构是客户端和服务端均相信的第三方；
首先，服务端会向CA申请公钥，数字证书认证机构在验明服务端身份后对申请的公钥做数字签名，然后将已签名的公钥放入公钥证书；服务端会携带公钥证书给客户端以开启公钥加密方式通信；
客户端收到携带数字证书的请求后，使用CA的公钥对证书上的签名进行验证，通过后则可以认为：
- 数字认证机构是有效的；
- 服务器的公钥是有效的；
所以CA的公钥的正确性如何保证呢？一般浏览器会内部植入常用认证机构的公钥；
对于安全性极高的认证机构，可以颁发客户端证书，但仅用于特殊用途的业务；同时，也可以通过OpenSSL搭建自己的认证机构，从而自己给自己颁发服务器证书，这种自认证机构颁发的证书也被戏称为“自签名证书”；自签名证书顶多对外宣称“我是ABC”，但是作为客户端无法验证正在通信的服务器真的是“ABC”；
HTTPS的具体通信过程为：
- 客户端发送Client Hello报文，指定SSL版本、加密组件列表（包括加密算法以及秘钥长度）；
- 服务端响应Server Hello报文，指定SSL版本以及加密组件（从客户端支持的加密组件中选出）；
- 服务端发送Certificate报文，包含公开秘钥证书；
- 服务端发送Server Hello Done 报文，SSL握手协商阶段结束；
- 客户端发送Client Key Exchange报文，包含通信加密中使用的Pre-master secret随机密码串，使用公钥加密；
- 客户端发送Change Cipher Spec报文，此报文之后，均使用Pre-master secret秘钥加密；
- 客户端发送Finished报文，包含连接至今全部报文的整体校验值，握手协商是否成功取决于服务端是否正确解密该报文；
- 服务端发送Change Cipher Spec报文；
- 服务端发送Finished报文；
- Finished报文发送完毕后，SSL连接建立完成；此处进行应用层协议通信，即发送HTTP请求；
- HTTP通信；
- 客户端断开连接，发送close_notify报文，之后便是TCP断开连接；
以上流程中，应用层会发送一种MAC的报文摘要（Message Authentication Code）报文摘要来查看报文是否被篡改；
以下为图解：
CBC（Cipher Block Chaining）密码分组链接模式；将前一个明文块加密处理后得到的密文块与当前明文块做XOR预算，之后再加密得到密文块；对第一个明文块加密时要么使用上一段密文的最后一块，要么利用外部生成的初始向量；
SSL最早由网景公司倡导，开发到3.0版本，后移交到IETF（Internet Engineering Task Force），IETF以SSL3.0为原型，制定了TLS1.0、TLS1.1以及TLS1.2；TLS以SSL为原型开发的协议，因此有时统一称为SSL，当前主流版本是SSL3.0和TLS1.0；
HTTP认证
认证信息一般包括：密码、动态令牌（本人持有且仅显示一次的动态密码）、数字证书（本人持有的终端）、生物认证（指纹、虹膜等）
HTTP1.1认证的方式有：
- Basic认证（基本认证）
- Digest认证（摘要认证）
- SSL客户端认证
- FormBase认证（基于表单的认证）
Basic认证是一种基本的认证方式：
- 当请求资源需要认证时，服务端会返回401（Authentication Required）状态码以及通过WWW-Authentication首部指定认证方式：Basic；
- 客户端将用户ID和密码以冒号:连接后进行base64处理；将处理结果写入Authorization首部后发送请求；
- 服务端进行信息的验证；如果通过则返回request uri首部指定资源的响应；
需要注意的是base64并不是一种加密算法，仅是一种编码方式；
Digest认证同样使用质询/响应的方式进行认证；服务端会发送质询码给客户端，客户端收到质询码后进行计算生成响应码，之后将响应码发送给服务端，以此完成身份认证；具体过程如下：
- 当请求资源需要认证时，服务端返回401状态码以及通过WWW-Authentication首部返回质询码；
- 客户端根据质询码计算出响应码，然后将username/质询码/响应码/请求uri发送给服务端；
- 服务端进行信息校验，通过后返回uri请求的资源；
Digest认证方式相比Basic来说更为安全，但是相比HTTPS和SSL客户端来说仍然比较弱；Digest认证防止了密码被窃听，但是并不存在防止伪装的保护机制；
SSL客户端认证，使用HTTPS的客户端证书完成认证，不过一般还会结合FormBase认证方式形成一种双因素认证的方式：其中SSL客户端用于认证设备，FormBase认证操作者本人；SSL认证具体过程如下：
- 当请求资源需要认证时，服务器发送Certificate Request报文，要求客户端提供客户端证书；
- 用户选择要发送的客户端证书后，客户端发送证书给服务端；
- 服务端进行校验；
该方法安全指数比较高，但是需要支付客户端证书的费用以及维护认证服务；
基于表单的认证比较常用，一般是将用户ID和密码等登录信息通过HTTPS提交给网站以此来决定是否认证成功；基于表单的认证标准尚未有规范，一般会使用Cookie来管理Session；具体过程如下：
- 客户端提交登录信息，通常通过HTTPS Post方法；
- 服务端发放标识用户的Session ID来标识认证状态；Session ID写入首部字段Set-Cookie；SessionID本身需要有一定的复杂性，无法伪造，同时也要有合理的生命周期；
- 客户端以Cookie的方式保存SessionID，并且在后面的请求中携带该值；
服务端一般先给密码加盐，然后进行hash计算出散列值后保存；
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
