目录

第一章 基础知识

HTTP协议 是完成从客户端到服务器端等一系列运作流程的规则与约定。可以说，Web是建立在HTTP协议上通信的。

WWW这一提议是致力于全世界的研究者们进行知识共享。

3项WWW构建技术：SGML（标准通用标记语言），HTML（超文本标记语言），URL（统一资源定位符）。

HTTP 协议属于 TCP/IP 协议族的一个子集。

TCP/IP分层管理：

• 应用层：决定了向用户提供应用服务时通信的活动。
• 传输层：提供处于网络连接中的两台计算级之间的数据传输。
• 网络层（网络互联层）：处理网络上流动的数据包。规定通过怎样的路径到达对方计算机，并把数据包传送给对方。
• 链路层：一切硬件相关的处理都在此处。

通信方式：层层递进，步骤封装。
IP：IP协议的简称，主要作用是把各种数据包发送给对方。而要保证却是传送到对方处，则需要满足各种条件。其中两个重要条件是IP地址和MAC地址。
IP地址：指明了节点被分配到的地址。
MAC地址：网卡所属的固定地址。
IP地址可以与MAC地址进行配对。IP地址可能会经常变换，但是MAC基本上不会变（除非更换网卡硬件）。
DNS服务：解析域名（方便人脑记忆）为数字（方便计算机存储）地址。
URI：统一资源标识符。
URL：统一资源定位符。URL是URI的子集。
URI格式：拆分理解：
【例】http://user:pass@www.jianshu.com:8080/writer/notes?chart=1#note1
1）协议名：http:// (必须项)
2）登录信息（认证）：user:pass@
3）服务器地址：www.jianshu.com，可以是Ipv4，也可以是Ipv6 (必须项)
4）服务器端口号：:8080（不设置则为默认端口）
5）带层次的文件路径：/writer/notes
6）查询字符串：?chart=1
7）片段标识符（锚点）**#note1

RFC：以此称谓一些用来制定HTTP协议技术标准的文档。

并不是所有应用程序都符合 RFC，不按照RFC标准执行可能会导致无法通信，然而大多数通信都符合RFC标准。

没有人能够全面掌控互联网中的传输状况：类比实例==>快递公司派送快件（中间的中转站无法预估）。
为确保信息已经送达（TCP/IP三次握手）：类比对象==>市场交易（
第一次握手：“你家卖的那个菠萝多少钱一个？”
第二次握手：“我家卖的这个菠萝，要你7块钱一个。”
第三次握手：没有对话，我递出7块钱给卖家。
交易结束，交易成功。
）
通讯过程
DNS代理之后：
【HTTP协议职责】：声称针对目标服务器的HTTP请求报文。
【TCP协议职责】：为方便通信，将HTTP请求报文分段，将每个报文段发送给对方
【IP协议职责】：搜索对方地址，一边中转一边传送。

HTTP是无状态协议，之所以这样设计是为了更快地处理大量事物，确保协议的可伸缩性。为了管理登陆等状态，后有 Cookie 技术的引入。

HTTP请求方法：
GET：获取资源。
POST：传输实体主体。
PUT：传输（上传）文件。要求在报文主体中包含文件内容，然后保存到请求URI的指定位置。（安全性问题：HTTP/1.1 PUT方法自身不带验证机制）
HEAD：获得报文首部，与GET方法一样，只是不返回报文主体。用于确认URI有效性及资源更新日期时间等。
DELETE：删除文件。与 PUT 相反的方法。
OPTIONS：询问支持的方法。
TRACE：追踪路径。可以让服务器端将之前的请求返回给客户端的方法。用以确认在连接过程中（有代理的情况下）发生的一系列操作。（容易引发 XST攻击，不常用）
CONNECT：要求用隧道协议链接代理。

持久连接：HTTP/1.1 开始支持持久连接，即只要没有任意一端声明断开连接，则保持TCP连接状态。
管线化：类似异步操作、多线程等概念。目的：快速响应。

Cookie：一种直接往HTTP报文首部添加的属性字段，用于保存一些状态。

第二章 HTTP 报文内部

• 报文由报文首部和报文主体构成。
• 向待发送邮件内增加附件时，为了使邮件容量变小，会先将文件压缩之后再发送。一般有如下压缩方式：
  • gzip（GNU zip）
  • compress（UNIX 系统的标准压缩）
  • deflate（zlib）
  • identity（不进行编码）
• 发送邮件时可以在邮件里写入文字并添加多份附件（这是因为采用了MIME机制），可处理文本、图片、视频等多种类数据。使用多部分对象集合时要加上 Content-type 首部字段。使用多部分对象集合包含的对象如下：
  • multipart/form-data 在 Web 表单文件上传时使用。
  • multipart/byteranges 响应报文包含多范围内容（状态码206）时使用。
• 范围获取（恢复下载）。指定范围的内容，获取多重范围内容的请求要在请求首部添加 Content-type：multipart/byteranges 以标明。如果服务器无法响应范围请求，则返回状态码200，并返回所有内容（完整实体）。

第三章 状态码

总览：
1xx || informational（信息性状态码）|| 接收的请求正在处理
2xx || Success （成功状态码） || 请求正常，处理完毕
3xx || Redirection（重定向状态码） || 需要进行附加操作以完成请求
4xx || Client Error（客户端错误码） || 服务器无法处理请求
5xx || Server Error（服务器错误代码）|| 服务器处理请求出错

• 200 OK
• 204 No Content
  • 请求处理成功，但是没有资源可返回。不允许报文中含有实体主体，浏览器页面不发生更新。
• 206 Partial Content
  • 成功处理了范围请求。
• 301 Moved Permanently
  • 永久性重定向。请求的资源已经被分配到了新的URI，以后应使用资源现在所指的
    URI。
• 302 Found
  • 临时性重定向。请求的资源已经被分配到了新的URI，希望用户本次能够使用心得URI访问。
• 303 See Other
  • 由于请求的资源存在着另一个URI，应使用GET方法定向获取请求的资源。

301、302标准十进制将POST改为GET的，但实际使用时大家并不遵守。几乎所有的浏览器都会不守此规。

• 304 Not Modified
  • 当客户端发送条件请求时，资源已找到，但未能符合条件请求。响应报文中不含主体。

304 虽为 3xx，但是跟重定向没有关系。

• 307 Temporary Redirect
  • 与 302 大致相同，遵守浏览器标准，不会将POST改为GET。
• 400 Bad Request
  • 请求有误（多为语法错误）。服务器无法处理此请求。
• 401 Unauthorized
  • 认证不通过
• 403 Forbidden
  • 不允许访问某资源。请求资源的访问被服务器拒绝了，并且服务器无必要给出拒绝理由。
• 404 Not Found
  • 找不到请求的资源
• 500 Internal Server Error
  • 服务器内部错误（各种可能）。
• 503 Service Unavilable
  • 服务器超载（正忙）或停机维护，现在无法处理请求。

状态码与实际状况可能不一致。比如web应用程序内部出错，但是状态码依然是200ok，这类情况时有发生。排查 bug 应视情况而定。

历史

1990年，大家针对HTML 1.0 草案进行了讨论，因 HTML 1.0 中存在多处模糊不清的部分，草案直接被废弃了。HTTP/0.9 问世。
1990年11月，CERN（欧洲核子研究组织）成功研发了世界上第一台Web服务器和Web浏览器。
1991年8月6日，世界上第一个网站 http://info.cern.ch 上线。
1992年9月，日本第一个网站的主页 http://www.ibarakiken.gr.jp/www/ 上线。
1993年1月，现代浏览器的祖先 NCSA（美国国家超级计算机应用中心）研发的Mosaic浏览器问世。同年秋天， Mosaic 的 windows版 和 Macintosh版 面世。使用CGI技术的NCSA web服务器、NCSA HTTPd 1.0 差不多也是这个时候出现的。
1994年5月15日，中国第一个网站“中国之窗”上线。
1994年12月，网景通信公司发布了Netscape Navigator 1.0。
1995年微软公司发布了Internet Explorer 1.0 和 2.0。
同时期，Apache 0.2 面世；HTML 2.0发布。第一次浏览器大战爆发（网景公司与微软之间），他们均有无视国际标准的对自HTML进行扩展的行为，导致开发的兼容性问题。
1996年5月，HTTP/1.0 正式作为标准被公布。
1997年1月，公布了 HTTP/1.1 ，此后便再没有什么改动。
2000年前后，网景公司衰落，第一次浏览器大战告一段落。
2004年，Mozilla 基金会发布了 FireFox 浏览器，第二次浏览器大战爆发。IE 浏览器版本从 6 升到 7 花费了约五年时间。之后接连发布 8、9、10。Chrome、Opera、Safari 等浏览器开始纷纷抢占市场份额。