1. URL是浏览器寻找信息时所需的资源位置，描述资源的位置来表示资源
2. URI是通用的资源标识符，URI由URL和URN组成，通过名字来识别资源，与所处位置无关。
3. HTTP所处理的知识URL子集，有时两者不加以区分，均指URL。
4. URL分为以下三部分
1. http:// ：是URL方案，告知Web客户端怎样访问资源，说明要使用http协议
2. 网址，主机名：是指服务器的位置
3. 后面的路径：是指资源路径，水命请求的是服务器上的哪个特定资源。
5. URL语法：方案://用户:密码@主机:端口/路径;参数?查询#片段
1. 其中参数是为了符合协议所需的信息，前面使用； 与路径进行分割
2. 查询会发送给服务器，片段则由客户端自行处理
6. 相对URL： ./ ：表示相对于 方案://主机名 的位置
7. 自动扩展URL
1. 主机名扩展：比如输入baidu就会构建出www.baidu.com
2. 历史扩展：将以前用户访问过的URL历史存储起来，输入URL时会与历史记录中的URL金顶比对
8. URL字符集与编码机制：
1. 字符集：使用的是 US-ASCII字符集，其使用7位二进制码来便是英文打字机提供的大多数按键与少数用于文本格式和硬件通知的不可打印控制字符
2. 编码机制：为了避开安全字符集表示法打来的限制，该表示法来表示不安全字符，包含一个百分号%，后面接着两个表示字符ASCII码的十六进制数
3. 字符限制：一些具有特殊含义的字符不建议使用，如% / , .. # ? ; : $ + @ & = 等
9. 常见的一些方案：http https mailto ftp rtsp rtspu file news telnet
10. URL会告诉资源所处的位置，如果资源被移动了，则位置无效。URN所解决的就是这个问题

1. HTTP报文是在HTTP应用程序之间发送的数据块。
1. 术语：流入和流出来描述事务处理的方向。报文流入源端服务器，工作完成后会流回用户的代理
2. 所有报文都会向 下游 流动，所有报文的发送者都在接受者的上游。
2. 报文的组成部分：
1. HTTP报文是简单的格式化数据块，每条报文都包含一条来自客户端的请求或者一条来自服务器的响应
2. 它们由三个部分组成：对报文进行描述的起始行、包含属性的首部块、可选的包含数据的主体部分
3. 报文的语法：
1. 所有报文均可以分为两类：请求报文、响应报文
2. 请求报文格式：

4. 起始行：所有HTTP报文都以一个起始行作为开始，请求报文的起始行说明要做些什么，响应报文的起始行说明发生了什么
1. 请求报文的起始行称为请求行，所定义的方法有GET POST DELETE HEAD PUT TRANCE OPINIONS 等常用方法，方法是用来告诉服务器要做什么事情
2. 状态码：告诉客户端发生了什么事情
1. 100~199：已定义100~101，表示信息提示
2. 200~299：已定义200~206，表示成功
3. 300~399：已定义300~305，表示重定向
4. 400~499，已定义400~415，表示客户端错误
5. 500~599，已定义500~505，表示服务器错误
3. 原因短语：与状态码是成对出现的，原因短语是状态码的可读版本
4. 版本号， HTTP/X.Y 的形式，声明了最高支持的版本
5. 首部：键值对的列表
1. 通用首部
2. 请求首部：提供请求信息
3. 响应首部：提供响应信息
4. 实体首部：描述主体的长度和内容，或者资源自身
5. 扩展首部：规范中没有定义的新首部
6. 实体主体部分，实体的书体是HTTP报文的负荷，就是需要传输的内容，可以传输的类型：图片，视频，HTML，软件应用程序，信用卡事务，email等
7. 方法：
1. 安全方法：GET和HEAD方法称为安全方法，使用这两个方法的HTTP请求不会产生什么动作
2. GET：通常用于请求服务器发送某个资源
3. HEAD：与GET类似，但服务器在响应中只返回首部，不返回实体的主体部分
1. 在不获取自愿的情况下了解资源的情况
2. 通过查看响应中的状态码看看某个对象是否存在
3. 通过查看首部，测试资源是否被修改了
4. PUT：向服务器写入文档。如有些发布系统允许用户创建Web界面，则使用put方法将其安装到Web服务器上去
5. POST：起初是用来向服务器输入数据的；实际上通常会用它来支持HTML的表单，将填好的数据发送到服务器。
6. TRACE：客户端请求经过中间节点时可能会修改原始的HTTP请求，TRACE方法的最后一站服务器会弹出一条TRACE响应，响应的主体中可以查看原始请求报文以及所有中间应用程用户程序。可以用来查看中间程序对用户请求产生的效果
7. OPTIONS：请求Web服务器告知其支持的各种功能
8. DELETE：请服务器删除请求URL所指定的资源，但是客户端应用程序无法保证删除操作一定被执行
9. 扩展方法
8. 状态码：
1. 1XX：信息性状态码：HTTP/1.1中向协议引入的
1. 100，Continue：说明收到了请求的初始部分
2. 101，Switching Protocols：说明服务器正在根据客户端的指定，将协议切换成Update首部所列的协议
2. 2XX：成功状态码
1. 200，OK：表示请求没问题
2. 201，Created：用户创建服务器对象的请求
3. 202，Accepted：请求已被接受，但服务器还未对其执行任何动作
4. 203，实体首部包含的信息不是来自于源端服务器，而是来自资源的一份副本
5. 204，No Content：响应报文中包含若干首部和一个状态行，但是没有实体的主体部分
6. 205，Reset Content：主要用于浏览器的代码，负责告知浏览器清除当前页面中的所有表单元素
7. 206，Partial Content：成功执行了一个部分或Range请求
3. 3XX：重定向状态码
1. 300，Multiple Choices：客户端请求一个实际指向多个资源的URL
2. 301，Moved Permanently：请求URL已被移除，响应的Location首部包含资源现在所处的URL
3. 302，Found：与301类似，但客户端应使用Location首部给出的URL来临时定位资源，将来的请求仍使用老的URL
4. 303，See Other：告知客户端应该用另一个URL来获取资源
5. 304，Not Modified：资源未被修改，本地资源是最新版本
6. 305，Use Proxy：必须通过一个代理来访问资源
7. 307，Temporary Redirect：与301类似
4. 4XX：客户端错误状态码
1. 400，Bad Request：告知客户端发送了一个错误的请求
2. 401，Unauthorized：客户端在获取对资源的访问权之前，需要对自己进行认证
3. 402，Payment Required：该状态码保留
4. 403，Forbidden：请求被服务器拒绝，响应的主体部分会对原因进行描述
5. 404，Not Found：服务器无法找到所请求的URL
6. 405，Method Not Allowed：请求的URL不支持该方法
7. 406，Not Acceptable：服务器没有与客户端客机首的URL相匹配的资源
8. 407，Proxy authentication Required：与401类似，但要求对资源进行认证代理服务器
9. 408，Request Timeout：客户端完成请求所花的时间太长
10. 409，Conflict：请求可能在资源上引发一些冲突
11. 410，Gone：与404，但服务器曾经有该资源
12. 411，Length Required：服务器要求在请求报文中包含Content-Lnegth首部时使用
13. 412，Precondition Failed，客户端发起了条件请求，但其中一个失败了
14. 413，Request Entity Too Large：客户端发送的主体部分太长
15. 414，Request URI Too Long：发送的请求URL太长
16. 415，Unsuuported Media Type：无法理解或无法支持客户端所发送的实体内容类型
17. 416，Request Range Not Satisfiable：请求报文锁清秋的是指定资源的某个范围，而该范围无效或无法满足
18. 417，Expectation Failed：请求的Expect请求首部包含了一个期望，但是服务器无法满足该期望
5. 5XX，服务器错误状态码
1. 500，Internet Server Error：服务器遇到了一个妨碍它为请求提供服务的错误
2. 501，Not Implemented：客户端发起的请求超出服务器的能力范围
3. 502，Bad Gateway：作为代理或网关使用的服务器从请求响应收到了一条伪响应，如无法连接父网关
4. 503，Service Unavailable：服务器暂时无法为请求提供服务
5. 504，Gateway Timeout：与408类似，只是这里的响应来自一个网关或代理
6. 505，HTTP Version Not Supported：服务器收到的请求使用了它无法或不愿支持的协议版本
9. 首部：与方法共同决定了客户端和服务器能做什么事
1. 通用首部：与报文相关的最基本的信息
1. Connection：允许客户端和服务器指定与请求/相应连接有关额选项
2. Date：提供日期和事件标志，说明报文的创建时间
3. MIME-Version：给出了发送端使用的MIME版本
4. 通用缓存首部：Cache-Control用于随报文传送缓存指示；...
5. ...
2. 请求首部
1. Client-IP
2. From
3. Host
4. Referer
5. ...
6. Accept首部：告知服务器能够发送哪些媒体类型、字符集、编码方式、语言等
7. 条件请求首部：客户端希望为请求加上某些限制，Expect
8. 安全请求首部：对请求进行质询/响应认证
9. 代理请求首部
3. 响应首部：为客户端提供了一些额外信息
1. 协商首部
2. 安全响应首部
4. 实体首部：提供了有关实体及其内容的大量信息
1. 内容首部：提供了与实体内容有关的特定信息
2. 实体缓存首部：说明如何或什么时候进行进行缓存
5. 扩展首部

1. TCP/IP是全球计算机及网络设备都在使用的一种常见的分组交换网络分层协议集。
2. TCP为HTTP提供了一条可靠的比特传输管道，从TCP连接一段填入的字节会从另一端以原有的顺序，正确的传送出来。TCP流式通过名为IP分组的小数据块来发送的。HTTP要传送一条报文的时候，会以流的形式将报文数据的内容通过一条打开的TCP连接按序传输。TCP收到数据流之后，会将数据流砍成被称作段的小数据块，并将段封装在IP分组中，通过因特网来传输。

3. TCP是通过端口号来保持所有这些链接的正确运行的。而TCP连接时通过4个值来进行识别的：源ip地址，源端口号，目的ip地址，目的端口号，没有两个不同的连接所有的4个值都一样。
4. 套接字socket:
1. 服务器端：
1. 创建套接字 create
2. 绑定端口 bind
3. 进行监听 listen
4. 等待连接 accept
5. 读取请求并处理 read
6. 回传响应 write
7. 关闭连接 close
2. 客户端
1. 创建套接字 create
2. 连接到服务器IP:port上 connect (这里建立一条道服务器的TCP连接)
3. 连接成功并发送请求 write
4. 接收并处理响应 read
5. 关闭连接 close
5. HTTP时延主要是由于TCP网络时延构成的，HTTP事务的时延主要有以下几个原因：
1. 客户端需要根据URI来确定Web服务器的IP地址与端口号，DNS解析系统没有缓存的话可能需要数十秒
2. 客户端会向服务器发送一条TCP连接请求，并等待服务器回传一个请求接受应答，每个TCP连接都会有建立时延，最多2秒
3. 连接建立之后，客户端需要发送请求，服务器需要对请求进行处理。而因特网传输请求报文以及服务器处理请求报文都需要时间。
4. Web服务器会回传HTTP响应，需要花费时间
5. 另外，这些TCP网络时延的大小取决于应减速度、网络以及服务器的负载，请求和响应报文的尺寸以及客户端与服务器之间的距离。外加TCP协议的技术复杂性

6. TCP连接握手步骤

1. 请求新的TCP连接，客户端要想服务器发送一个小的TCP分组，分组中设置了SYN标记，说明是一个连接请求
2. 服务器接受请求并处理，回传一个TCP分组，这个分组中SYN与ACK标记都被置位，表示已被接受
3. 客户端向服务器回传一条确认信息，通知连接已成功建立

　　7. 延迟确认：每个TCP段的接受者收到完好的段时，都会向发送者回传小的确认分组。如果发送者在指定时间内没有收到的话，则认为分组被破坏，并重发数据。

　　8. HTTP连接的处理 ---> 没看懂

1. connection首部字段可以承载三种不同类型的标签
1. http首部字段名，列出了只于此链接有关的首部
2. 任意标签值，用于描述此链接的非标准选项
3. 值close，说明操作完成之后需要关闭这条持久的连接
2. 串行事务处理时延
1. 缺点：有的浏览器在对象加载完成之前无法获得对象的尺寸，无法确定位置。所以在加载足够多的对象之前，屏幕是一片空白，用户体验度很低。
2. 解决所需要的技术：并行连接(多条TCP连接)、持久连接(重用TCP连接)、管道化连接(利用共享的TCP连接)以及复用的连接(仍在实验阶段)

　　9. 并行连接：HTTP允许客户端打开多条连接，并行的执行多个HTTP事务

1. 并行连接可能会提高页面的加载速度：发送请求事务是重叠的，连接的时延也是重叠的
2. 并行连接不一定更快：当客户端的网络带宽本来就不足时，并行加载多个对象会竞争带宽；同时大量连接会消耗很多内存资源
3. 并行连接可能会让人“感觉”快一点

　　10. 持久连接：HTTP/1.1允许HTTP设备在事务处理结束之后将TCP连接保持在打开状态，一遍将来的HTTP请求重用现存的连接。非持久连接会在每个事务结束自后关闭，持久连接会在不同事务之间保持打开状态，直到客户端或者服务器决定将其关闭为止。...

　　11. 管道化连接：在响应到达之前，可以将多条请求放入队列，当第一条请求通过网络流向服务器端的时候，第二条、第三条请求也可以开始发送了，这样做可以降低网络的环回时间，提高性能。管道连接有如下限制：

1. 如果http客户端无法确认连接是持久的，则不应使用管道
2. 必须按照与请求相同的顺序会送HTTP响应
3. HTTP客户端必须做好连接会在任意时刻关闭以及重发所有未完成的管道化请求的准备
4. HTTP客户端不应使用管道化的方式发送产生副作用的请求，比如POST

　　12. 关闭连接：

1. Content-Length及截尾操作：如果实际长度与Content-Length不符，则接收端应当质疑长度的正确性；缓存代理不应缓存该响应
2. 如果一个事务不管是执行一次还是多次，得到的结果都是相同的，则这个事务就是幂等的，比如GET/HEAD/PUT/DELETE/TRACE/OPTIONS等方法。而客户端不应当管道化非幂等事务，比如POST等，否则就会造成一些不确定的后果，要发送一个非幂等事务需要等待前一条请求的相应状态。
3. 正常关闭连接，TCP连接是双向的。套接字盗用close()方法关闭TCP连接会将输入和输出信道都关闭，为完全关闭。调用shutdown()单独关闭输入或输出信道，被称为半关闭。简单的HTTP应用程序只能使用完全关闭。当客户端或者服务器需要突然关闭一条连接时，应当“正常的关闭传输连接”。
4. 关闭输入/输出是针对服务器而言的。关闭连接的输出信道比较安全，连接的另一端对等实体会在从起缓冲区中读出所有树之后收到一条通知，说明流结束了。关闭连接的输入信道比较危险，大部分操作系统会将这种情况当做很严重的错误来处理。

1. 私有和共享代理：单个客户端专用的代理称为私有代理，多个客户端共享的代理称为公共代理
1. 公共代理：大多数都是这种，容易管理
2. 私有代理，不太常见
2. 代理和网关的对比：
1. 代理连接的是两个或多个使用相同协议的应用程序
2. 网关连接的是两个或多个使用不同协议的端点，扮演着“协议转换器”的角色
3. 实际过程中，代理也经常要做一些协议转换工作。
3. 代理的功能：改善安全性，提高性能，节省费用；代理服务器可以看到并接触到所有流过的HTTP流量，所以代理可以监视流量并对其进行修改。下面是一些使用实例：
1. 儿童过滤器：实现过滤器的功能
2. 集中式文档访问控制：在Web服务器与Web资源之间实现统一的访问控制策略，创建审核跟踪机制
3. 安全防火墙：在单一安全节点上限制哪些应用层协议的数据可以流入或流出一个组织，还可以对流量进行检查，来消除病毒
4. Web缓存：维护了常用文档的本地副本，并将它们按需提供，以减少缓慢且昂贵的因特网通信
5. 反向代理：代理可以假扮Web服务器，接收发给Web服务器的真实请求，然后它们可以发起与其他服务器的通信，以便按需定位所请求的内容。可以用来访问慢速Web服务器上公共内容，提高性能。被称为服务器加速器
6. 内容路由器：可以根据因特网流量状况以及内容类型将请求到想到特定的Web服务器上
7. 转码器：将内容发送给客户端之前可以修改内容的主体格式，这些数据的表示法之间进行透明的转化被称为转码。
8. 匿名者：会自动从HTTP报文中删除身份特征信息，从而提供高度的私密性和匿名性。
4. 代理服务器的部署
1. 出口代理：固定在本地网络的出口点，控制流量
2. 访问(入口)代理：放在ISP访问点上，处理来自客户端的聚合请求
3. 反向代理：部署在网络边缘，作为Web服务器替代物使用，处理发送给服务器端的请求，必要时向服务器请求资源，用以提高性能。
4. 网络交换代理：放在网络之间的因特网对等交换点上，减轻节点的拥塞
5. 代理的层次结构
1. 静态代理
2. 动态代理：选择父代理
1. 负载均衡
2. 地理位置附近的路由
3. 协议/类型路由
4. 基于订购的路由
6. 代理的流量获取方法：
1. 修改客户端：浏览器的手动或自动的代理设置
2. 修改网络：这种拦截通常依赖于监视HTTP流量的交换设备以及路由设备，并将流量导入代理，称为“拦截代理”
3. 修改DNS命名空间：放在Web服务器之前的代理服务器，可以手动编辑DNS列表确定适当的代理或服务器
4. 修改Web服务器：将某些Web服务器配置为向客户端发送一条305HTTP重定向命令，将客户端请求重定向到一个代理上去
7. 客户端的代理设置 (注：网络、DNS、服务器配置方式在第20章)
1. 手工配置：如IE的Internet选项中进行代理的手动配置，只能设置唯一一个代理服务器
2. 预先配置服务器：利用PAC文件，一个小型JS程序，可以计算代理设置，配置方法与a类似
3. 代理的自动配置：提供一个URI指向一个JS所写的代理自动配置文件并运行决定是否使用代理
4. WPAD(Web代理自动发现协议)的代理发现：会自动检测所出应该从哪个配置服务器下载自动配置文件。该协议的算法会使用发现机制，逐级上升策略自动的为浏览器查找合适的PAC文件。WPAD使用多种发现技术，其顺序为(DHCP、SLP、DNS知名主机名、DNS SRC记录、TXT记录中的DNS服务URI)。实现WPAD协议的客户端需要：
1. 用WPAD找到PAC的URI
2. 从指定的URI获取PAC文件
3. 执行PAC文件来判定代理服务器
4. 为请求使用代理服务器
8. 关于代理请求的一些问题
1. 代理URI与服务器URI不同，客户端向Web服务器发送的请求，请求行只有部分URI(没有方案、主机或端口)，但客户端向代理发送请求时，请求航则包含完整的URI
1. 这是以为内在原始的HTTP设计中，客户端回直接与单个服务器进行对话，不存在虚拟主机，也没有为代理指定什么规则，而单个服务器知道自己的主机名和端口
2. 因此我们要将部分URI发送给服务器，将完整的URI发送给代理；同时，没有设置客户端代理的时候，会发送部分URI；设置了代理则发送完整的URI
2. 与虚拟主机一样的问题：缺少“方案/主机/端口”
1. 显示的代理要求在请求报文中使用完整的URI来解决
2. 虚拟主机Web服务器要求使用Host首部来承载主机和端口信息
3. 拦截代理会收到部分URI：客户端并不总是知道它在和代理进行对话，有的代理对客户端是不可见的；客户端流量可能经过替代物或者拦截代理；以上两种情况下不会发送完整的URI
1. 反向代理通常会假扮服务器主机名或IP地址来作为反向代理。客户端无法区分反向代理与Web服务器，因此它会发送部分URI
2. 拦截代理：拦截了从客户端发送到服务器的请求，并对其进行转发。会受到发送给Web服务器的部分URI
4. 代理既可以处理代理请求，也可以处理服务器请求
1. 如果提供的是完整的URI，则代理就应该使用完整的URI
2. 如果提供的是部分URI，而且有HOST首部，就应该用HOST首部来确定原始服务器的名字和端口号
3. 如果提供部分，而且没有HOST首部，就应该用其他方式来确定原始服务器
5. 转发过程中对URI的修改：...
6. URI的客户端自动扩展和主机名解析：常见用户没有输入前缀www或后缀.com的情况，浏览器会自动扩展
7. 没有代理时URI的解析：输入->DNS搜索主机‘aaa’->搜索失败->浏览器自动扩展为www.aaa.com->DNS搜索主机‘www.aaa.com’->返回IP地址->浏览器尝试连接，直到成功建立连接为止
8. 有代理时URI的解析：输入‘aaa‘->DNS去搜索代理服务器的地址->获取代理服务器的IP地址->浏览器进行自动扩展www.aaa.com->浏览器试图进行连接，直到成功为止
9. 有拦截代理时的URI解析：对于客户端来说就是没有代理，与h类似
9. 追踪报文
1. via首部：列出了与报文途径的每个中间节点有关的信息，包括协议名(可选)，协议版本，节点名，注释(可选)
2. via请求和响应路径：响应路径与请求路径相反
3. via与网关：via首部记录网关内的协议转换
4. Server和via首部
5. via的隐私与安全问题：via字符串中应避免使用确切的主机名和端口号，有可能会被恶意利用，可以进行压缩处理
10. TRACE方法：用户可以跟踪径代理链传输的请求报文，查看经过了哪些代理，以及每个代理是如何队请求报文进行修改的；可以利用Max-Forwards参数来设置最大转发次数，当达到最大转发次数为0后，TRACE报文会会送给客户端；每转发一次，该参数就会减一。
11. 代理认证：阻止访问设备对其内容的请求，直到用户向代理提供了有效的权限证书
1. 受限内容请求到达代理服务器，回传407状态码，以及描述怎样提供这些证书的Proxy Authorization首部字段
2. 客户端收到407，会从本地数据库中或者提示用户来收集所需要的证书
3. 获得了证书，客户端就会从新发送请求，并在首部字段中提供要求的证书
4. 如果证书有效，则代理将请求向下传送；否则是另一条407应答
12. 代理的互操作性
1. 处理代码不支持首部和方法
2. OPTIONS方法：发现对可选特性的支持客户端可以在与服务器交互之前确定服务器的能力
3. Allow首部：列出了请求URI支持的方法列表；如Allow: GET, HEAD, PUT；代理不能对Allow首部字段进行修改