第一章、了解web及网络基础
1.2 http的诞生
HTTP于1990年问世，那时候HTTP并没有作为正式的标准被建立，被称为HTTP/0.9
HTTP正式作为标准被公布是在1996年5月，版本被命名为HTTP/1.0，该协议至今仍被广泛用在服务器端。
HTTP/1.1于1997年1月公布，是目前主流的HTTP协议版本。
HTTP/2.0正在制定中。
1.3 TCP/IP
TCP/IP不是某个协议，而是互联网相关的各类协议族的总称。详细内容参见TCP/IP详解学习笔记
TCP/IP协议族按层次分别为以下4层：
应用层：决定了向用户提供应用服务时的通信活动，该层包括FTP DNS HTTP
传输层：对上层应用层，提供处于网络连接中的两台计算机之间的数据传输，该层包括TCP UDP
网络层：用来处理在网络上流动的数据包，该层规定了通过怎样的路径达到对方计算机并把数据包传送给对方
链路层：用来处理连接网络的硬件部分，网卡 光纤
TCP/IP通信传输流程（http举例）
首先作为发送端的客户端在应用层（http协议）发出一个想看某个web页面的http请求。接着，为了传输的方便，在传输层（tcp协议）把从应用层处收到的数据（http请求报文）进行分割，并在各个报文上打上标记序号及端口号后转发给网络层。在网络层（ip协议）增加作为通信目的地的MAC地址后转发给链路层。这样，发往网络的通信请求就齐全了。
1.4.1 负责传输的IP协议
IP协议的作用是把各种数据包传送给对方
IP地址指明了节点被分配到的地址，MAC地址是指网卡所属的固定地址
1.4.2 确保可靠性的TCP协议
TCP协议为了更容易送达大数据才把数据分割，采用三次握手策略确保数据最终送达对方
三次握手策略：
发送端首先发送一个带SYN(synchronize)标志的数据包给对方，接收端收到后回传一个带有SYN/ACK标志的数据包以示传达确认信息。最后发送端再回传一个带ACK(acknowledgement)标志的数据包代表握手结束。
1.5 负责域名解析的DNS(Domain Name System)服务
DNS提供域名到IP地址之间的解析服务
1.6 各种协议在http协议通信过程中的职责
按流程顺序分别为：
DNS服务：把用户输入的域名解析为IP地址
HTTP协议：生成针对目标web服务器的HTTP请求报文
TCP协议：为了方便通信将HTTP请求报文分割成报文段，把每个报文段可靠的传给对方
IP协议：搜索对方的地址，一边中转一边传送
TCP协议：从对方那里接收报文段并按序号从组请求报文
HTTP协议：对web服务器请求的内容的处理
1.7 URI/URL
URI(Uniform Resource Identifier)某个协议方案的资源的定位标识符
URL(Uniform Resource Locator)表示互联网资源的具体地点
第二章、简单的http协议
2.2 通过请求和响应的交换达成通信
请求报文是由请求方法、请求URI、协议版本、可选的请求头部字段和内容实体构成的。
响应报文基本上是由协议版本、状态码、用以解释状态码的原因短语、可选的响应首部字段及实体主体构成。
2.3 HTTP是不保存状态的协议
HTTP协议自身不对请求和响应之间的通信状态进行保存
2.5 告知服务器意图的http方法
GET:用来访问已被URI识别的资源
POST:用来传输实体的主体
GET方法和POST方法的区别：
-
安全性
- GET请求的数据会附在URL之后（就是把数据放置在HTTP协议头中），以?分割URL和传输数据，参数之间以&相连，参数将明文出现在URL上，容易被他人看到，URL信息也可能会被记录到历史纪录中。
- POST请求是把提交的数据则放置在是HTTP包的包体中。
-
数据长度：
- HTTP协议没有对传输的数据和URL长度进行限制， 但特定浏览器和服务器对URL长度有限制， 因此对于GET提交时，传输数据就会受到URL长度的限制；
- 由于POST操作不是通过URL传值，理论上数据长度不受限；
-
GET请求能够被缓存,以GET请求的URL能够保存为浏览器书签，而POST请求则都不能
-
Get是用来从服务器上获得数据，而Post是用来向服务器上传递数据。
以下其他方法均不常用
PUT:传输文件 HEAD：获得报文首部 DELETE:删除文件 OPTUIONS:询问支持的方法 TRACK:追踪路径 CONNECT：要求用隧道协议连接代理
2.7 持久连接节省通信量
持久连接的好处在于减少了TCP连接的重复建立和断开所造成的额外开销，减轻服务器端荷载。在HTTP/1.1中所有连接默认都是持久连接
持久连接使得多数请求以管线化方式发送，即能同时并行发送多个请求。
2.8 使用cookie的状态管理
cookie技术是通过在请求和响应报文中写入cookie信息来控制客户端的状态
Cookie会根据从服务器发送的响应报文内的一个叫做Set-Cookie的首部字段信息，通知客户端保存cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入Cookie值后发送出去。服务器端接收到客户端发送过来的Cookie后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。
第三章、http报文内的http信息
3.1 HTTP报文
HTTP报文大致可分为报文首部和报文主体两块，两者有最初出现的空行来划分，通常并不一定要有报文主体
3.2 请求报文和响应报文的结构
请求行：包含用于请求的方法，请求URI和HTTP版本
状态行：包含响应结果的状态码，原因短语和HTTP版本
首部字段：包含表示请求和响应的各种条件和属性的各类首部，一般分别为：通用首部、请求首部、响应首部和实体首部。
其他：包含HTTP的RFC里未定义的首部（Cookie等）
3.3 编码提升传输速率
常用的内容编码方式有以下几种：
- gzip(GNU zip)
- compress(UNIX系统的标准压缩)
- deflate(zlib)
- identity(不进行编码)
3.5 获取部分内容的范围请求(Range Request)
执行范围请求时，会用到首部字段Range来指定资源的byte范围
针对范围请求，响应会返回状态码为206 Partial Content的响应报文
3.6 内容协商返回最合适的内容
内容协商机制是指客户端和服务器端就响应的资源内容进行交涉，然后提供给客户端最适合的资源。内容协商会以响应资源的语言、字符集、编码方式等作为判断的基准。如首部字段中的Accept、Accept-Charset、Accept-Enoding、Accept-Language、Content-Language
第四章、返回结果的http状态
4.1 状态码告知从服务器端返回的请求结果
| 类别 | Cool | |
|---|---|---|
| 1XX | informational(信息性状态码) | 接收的请求正在处理 |
| 2XX | Success(成功状态码) | 请求正常处理完毕 |
| 3XX | Redirection(重定向状态码) | 需要进行附加操作已完成请求 |
| 4XX | Client Error(客户端错误状态码) | 服务器无法处理请求 |
| 5XX | Server Error(服务器端错误状态码) | 服务器处理请求出错 |
4.2 2XX成功
200 OK 表示从客户端发来的请求在服务器端被正常处理
204 No Content 表示服务器接收的请求已成功处理，但返回的响应报文中不允许返回任何实体的主体部分
206 Partial Content 表示客户端进行了范围请求，服务器成功执行了这部分GET请求
4.3 3XX 重定向
304 Not Modified 表示客户端发送附带条件的GET请求时，其访问的资源（自上次访问以来或者根据请求的条件）未变化
4.4 4XX客户端错误
401 Bad Request 表示报文中存在语法错误
403 Forbidden 表示对请求资源的访问被服务器拒绝了
404 Not Found 表示服务器上无法找到请求的资源
4.5 5XX 服务器错误
501 Internet Sever Error 表示服务器端在执行请求时发生了错误
503 Service Unavailable 表示服务器暂时处于超负荷或正在停机维护，现无法处理请求
第五章、与http协作的web服务器
5.1 用单个虚拟主机实现多个域名
在相同的IP地址下，由于虚拟主机可以寄存多个不同主机名和域名的Web网站，因此在发送HTTP请求时，必须在Host首部内完整指定主机名或域名的URI
5.2.1 代理
代理服务器的基本行为接收客户端发送的请求后转发给其他服务器，代理不改变请求URI,转发时需要附加Via首部字段已标记出经过的主机信息。
使用代理服务器的理由：
- 利用缓存技术（代理缓存）减少网络带宽的流量
- 组织内部针对特定网站的访问控制，以获取访问日志为主要目的。
5.2.2 网关
网关能使通信线路上的服务器提供非HTTP服务（SQL数据查询）
5.2.3 隧道
隧道的目的是确保客户端能与服务器进行安全的通信
第六章、http首部
6.2.4 首部字段一览表
通用首部字段
| 首部字段名 | 说明 |
|---|---|
| Cache-Control | 控制缓存的行为 |
| Connection | 逐跳首部、连接的管理 |
| Date | 创建报文的日期时间 |
| Pragma | 报文指令 |
| Trailer | 报文末端的首部一览 |
| Transfer-Encoding | 指定报文主体的传输编码方式 |
| Upgrade | 升级为其他协议 |
| Via | 代理服务器的相关信息 |
| Warning | 错误通知 |
请求首部字段
| 首部字段名 | 说明 |
|---|---|
| Accept | 用户代理可处理的媒体类型 |
| Accept-Charset | 优先的字符集 |
| Accept-Encoding | 优先的内容编码 |
| Accept-Language | 优先的语言 |
| Authorization | web认证信息 |
| Expect | 期待服务器的特定行为 |
| Form | 用户的电子邮箱地址 |
| Host | 请求资源所在服务器 |
| if-Match | 比较实体标记ETag |
| if-None-Math | 比较实体标记 |
| if-Modified-Since | 比较资源的更新时间 |
| if-Unmodified-Since | 比较资源的更新时间 |
| if-Range | 资源未更新时发送实体byte的范围请求 |
| Max-Forwards | 最大传输逐跳数 |
| Proy-Authorization | 代理服务器要求的客户端认证信息 |
| Referer | 对请求中URI的原始获取方 |
| Range | 实体的字节范围请求 |
| TE | 传输编码的优先级 |
| User-Agent | http客户端程序的信息 |
响应首部字段
| 首部字段名 | 说明 |
|---|---|
| Accept-Range | 是否接受字节范围请求 |
| Age | 推算资源创建经过时间 |
| ETag | 资源的匹配信息 |
| Location | 令客户端重定向指定URI |
| Proxy-Authenticate | 代理服务器对客户端的认证信息 |
| Petry-After | 对再次发起请求的时机要求 |
| Server | HTTP服务器的安装信息 |
| Vary | 代理服务器缓存的管理信息 |
| WWW-Authenticate | 服务器对客户端的认证信息 |
实体首部字段
第七章、确保web安全的https
7.1http缺点
- 通信使用明文，内容可能被窃听
- 不验证通信方身份，有可能遭遇伪装
- 无法证明报文的完整性，有可能已遭篡改
7.2 HTTP+加密+认证+完整性保护=HTTPS
HTTPS并非应用层的一种新协议，只是HTTP通信接口部分用SSL和TLS协议代替而已，其实就是身披SSL协议这层外壳的HTTP
SSL采用一种叫做公开密钥加密的加密处理方式
加密和解密同用一个密钥的方式称为对称密钥加密
公开密钥加密使用一对非对称的密钥，私有密钥和公开密钥，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密
公开密钥加密处理起来比共享密钥加密方式更为复杂，因此若在通信时使用公开密钥加密方式，效率会很低。所以HTTPS采用采用共享密钥加密和公开密钥加密两者并用的混合加密机制
混合加密机制原理：
- 使用公开密钥加密方式安全的交换共享密钥（在稍后的共享密钥加密中要使用的密钥）
- 确保交换的秘钥安全的前提下，使用共享密钥加密方式通信。
第八章、确认访问用户身份的认证
第九章、基于http的功能追加协议
9.2 消除http瓶颈的spdy
http瓶颈：
- 一条连接上只可发送一个请求
- 请求只能从客户端开始，客户端不可以接收除响应以外的指令
- 请求/响应首部未经压缩就发送，首部信息越多延迟越大
- 发送冗长的首部，每次发送相同的首部造成的浪费较多
- 可任意选择数据压缩格式，非强制压缩发送
消除http瓶颈方法尝试:
- Ajax 能实时地从服务器获取内容，可能导致大量请求产生
- Comet 内容随可以实时更新，但为了保留响应，一次连接的持续时间变长了，消耗更多资源
- SPDY 虽然能有效消除瓶颈，但当一个web网站使用多个域名下的资源时，改善效果受限制
9.3 使用浏览器进行双全工通信的WebSocket
WebSocket协议主要特点：
- 支持由服务器向客户端推送数据功能
- 减少通信量，不但每次连接总开销减少，而且首部信息也很少
为了实现WebSocket通信需要将Http的Upgrade首部字段值设为websocket,对于之前的握手请求，返回状态码101 Switching Proticols.成功握手确立WebSocket连接之后，不再使用HTTP的数据帧，而采用WebSocket独立数据帧
WebSocket API
javascript可调用“The Websocket API”内提供的websocket程序接口，以实现websocket协议下双全工通信