简单易懂，非常适合用来入门，应该再早一些看的（2018.11.04 - 2018.12.21）
第一章 了解Web及网络基础
Web使用HTTP（HyperText Transfer Protocol，超文本传输协议）作规范。
3项WWWW构建技术：HTML/HTTP/URL
目前主流和HTTP协议主流版本是1.1，HTTP2.0正在制定中
网络基础 TCP/IP
通常使用的网络（包括互联网）是在TCP/IP协议族的基础上运行的，HTTP是其中的一个子集。
TCP/IP协议族按层次分为了四个层次：
- 应用层
- 传输层
- 网络层
- 数据链路层
应用层
TCP/IP内运存了各类通用的应用服务，比如FTP(File Fransfer Protocol)、DNS(Domain Name System)和HTTP
传输层
传输层对上层应用层，提供处于网络连接中的两台计算机之间的数据传输
在传输层有两个性质不同的协议：TCP(Transmission Control Protocol)和UDP(User Data Protocol)
网络层
网络层用来处理在网络上流动的数据包。
数据包是网络传输的最小数据单位。
网络层规定了通过怎样的路径（传输路线）达到对方计算机，并把数据包传给对方
IP协议属于网络层协议
数据链路层
用来处理连接网络的硬件部分。硬件上的范畴均处于链路层的作用范围之内。
TCP/IP通信传输流
利用TCP/IP进行网络通信时，会通过分层顺序与对方进行通信。发送端从应用层往下走，而接收端从链路层往上走。
发送端在层与层之间传输数据时，没经过一层时必定会打上一个该层所属的首部信息。反之，接收端在层与层传输数据时，没经过一层会把对应的首部消去。
IP协议
IP协议作用是把各种数据包传送给对方，需要满足两个条件：IP地址和MAC地址
IP地址指明了节点被分配到的地址，可变；MAC地址是指网卡所属的固件地址，一般不会更改。
在传输的中转过程中，会使用ARP协议，利用下一站中转设备的MAC地址搜索下一个中转目标。
ARP协议(Address Resolution Protocol)一种用以解析地址的协议，根据通信方的IP地址可以反查对应的MAC地址
没有人能够全面掌握互联网中的传输状况。在到达目标前的中转过程中，计算机和路由器等网络设备只能获悉很粗略的传输路线，这种机制称为路由选择。
TCP协议
TCP位于传输层，提供可靠的字节流服务。
字节流服务(Byte Stream Service)是指，为了方便传输，将大块数据分割成以报文段(segment)为单位的数据包进行管理
TCP协议是为了更容易传送大数据，才把数据分割，而且TCP协议能够确认数据最终是否送达到对方。
为了确保数据传输的可靠性，TCP协议采取了三次握手(three-way handshaking)策略。握手过程衡中使用了TCP的标志——SYN(synchronize)和ACK(acknowledgement)。
握手过程如下：
- 发送端首先发送一个带SYN标志的数据包给对方
- 接收端收到后，回送一个带有SYN/ACK标志的数据包以示传达确认信息
- 最后发送端再回传一个带ACK标志的数据包，代表握手结束。
DNS服务
DNS服务也位于应用层，提供域名到IP地址之间的解析服务。
各种协议与HTTP协议的关系
对于发送端：
- DNS协议负责解析出目标域名的IP地址
- HTTP协议负责生成针对目标Web服务器的HTTP请求报文
- TCP协议的职责：1. 将HTTP请求分割成报文段；2. 将每个报文段通过三次握手建立的连接可靠地传给对方
- IP协议的职责是搜索对方的地址，一边中转一边传输
对于接收端，是一个相反的流程。
URI和URL
URI是Uniform Resource Identifier的缩写，是由某个协议方案表示的资源的定位标识符，除了http之外，还有ftp、telnet、file等30种左右。
URI用字符串标识某一互联网资源，而URL表示资源的地址，URL是URI的子集。
URI例子：
绝对URI的格式：
第二章 简单的HTTP协议
HTTP协议一定是从客户端发出请求，服务端在没有收到请求时不会发出发送相应。
请求报文：
#请求行
#方法 URI 协议
POST a.com HTTP/1.1
#请求头
connection: keep-alive
content-type: application/json
content-length: 16
#请求实体
响应报文：
#状态行
#协议 状态码 状态描述
HTTP/1.1 200 OK
#响应头
Date: Tue, 10 Jul 2012 06:50:50 GMT
content-type: application/json
content-length: 16
#响应实体
HTTP是无状态的协议，HTTP协议自身不会保存请求和响应的通信状态。正因为此才引入了Cookie技术。
请求方法（注意都是大写字母）：
- GET：获取资源
- POST: 传输实体
- PUT：传输文件
- HEAD：传输报文首部，不会返回实体，用于检验资源有效性、返回更新日期等
- DELETE：删除资源
- OPTIONS：讯问对指定资源的支持的方法
- TRACE：追踪路径（不常用）
- CONNECT：建立隧道，使用SSL和TLS加密后传输
在不使用keep-alive时，每进行一次HTTP通信就要断开一次TCP连接，会造成性能浪费。
因此有了keep-alive，只要任意一段没有明确提出断开连接，则保持TCP连接状态。可以减少TCP反复断开、连接造成的性能浪费。
HTTP1.1中所有的连接默认都是持久连接。
注意：即便是持久连接，每次HTTP请求通信都需要发送完整的（包括大量重复的响应头）的HTTP请求。
持久链接使得管线化发送请求，也就是可以并发发送多个请求，不需要一个接一个等待响应了。
但是浏览器端对于同一个域名下请求的并发是有限制的，一般是6个，这就导致了Domian Hash技术的出现，将资源放在不同的域名下，增加并发请求数。
HTTP请求是无状态的，需要通过Cookie来实现状态管理，服务器在响应头中添加Set-Cookie信息，来让客户端保存信息。下次客户端再往服务器发送请求时会自动加入Cookie发送出去。
9
第三章 HTTP报文内的HTTP信息
HTTP协议可以将实体（请求或响应的有效载荷数据）进行压缩编码传输，编码后的实体由客户端负责解码。
传输大容量数据时，可以将实体主题数据分割为多块，让浏览器逐步显示页面，这种功能成为分块传输编码（Chunked Transfer Codeing）
HTTP协议中采纳了多部分对象集合，发送的报文主题内可以包含多类型实体，通常在图片、文本文件上传时使用，这是需要在首部字段加上Content-type，使用boundary划分多部分对象集合中的各类实体
HTTP可以指定请求一定范围的数据，叫做范围请求（Range Request），使用首部字段request指定范围：
Range: bytes=5001-5002
Range: bytes=5001
Range: bytes=5001-6000, 7001-8000
针对范围请求会返回状态码206（Partial Content），如果服务端无法响应范围请求，则会返回200和全部实体内容
HTTP协议有着内容协商机制，指的是服务端和客户端会就响应的资源内容进行协商，返回给客户端最适合的资源，内容协商会以请求报文中的某些首部字段为基准：
AcceptAccept-CharsetAccept-EncodingAccept-LanguageContent-Language
内容协商有三种类型：
- 服务器驱动协商（以请求的首部字段为参考，在服务器端自动处理）
- 客户端驱动协商（用户手动在浏览器或者脚本提供的可选项进行选择）
- 透明协商（上面两种的结合）
第四章 返回结果的HTTP状态码
1xx：信息性状态码，接收到的信息正在处理2xx：成功，请求正常处理完毕3xx：重定向，需要进行附加操作完成请求4xx：客户端错误，服务器无法处理请求5xx：服务器错误，服务器处理请求出错
200 OK
表示请求被正常处处理，并且返回了信息（返回的信息因请求方法的不同有所不同，例如HEAD方法只会返回首部，不会返回内容）
204 No Content
返回的响应中不包含实体的主题部分，用于客服端向服务器发送信息，对客户端不需要发送新消息内容的情况
206 Partial Content
表示服务器执行了对范围请求的响应，响应报文中有Content-Range指定范围的实体内容
301 Moved Permanently
永久性重定向。如果指定资源路径后面忘记加/，就会返回301
当发生301重定向时，浏览器会按照响应头中的Location地址重新发起请求
302 Found
临时重定向，希望用户本次用新的URI访问
304 Not Modified
请求为满足条件（服务端资源未发生改变），可以直接使用客户端未过期的缓存
400 Bad Request
请求报文中出现语法错误
401 Unauthorized
需要认证
403 Forbidden
访问被服务器拒绝，有可能是访问权限有问题等等
404 Not Fount
服务器无法找到请求的资源
500 Internal Server Error
服务器端在执行请求时发生了错误
503 Service Unavailable
服务器超负载，或者停机维护，现在无法处理请求
第五章 与HTTP协作的Web服务器
利用了虚拟主机（Virtual Host），一台HTTP服务器可以搭建多个Web站点
代理
具有转发功能的应用程序，可以接受客户端的请求转发给服务器，也可以接受服务器的响应并转发给客户端
不会改变URI
使用代理服务器的好处：
- 利用缓存技术减少网络带宽的流量
- 针对特定网站的访问控制
代理服务器有两种使用方法：
- 代理缓存，将资源副本饭是钢在代理服务器上，直接返给客户端
- 透明代理，不对报文做任何加工
网关
转发其他服务器通信数据的服务器，接收到客户端请求时可以像自己拥有数据一样对数据进行处理
和代理类似，但是网关可以使通信线路上的服务器提供非HTTP协议服务。
使用网关的好处：
- 提高通信的安全性，可以在客户端与网关的通信线路上加密
- 网关可以连接数据库，提供非HTTP协议服务
隧道
在客户端和服务器间中转，并保持双方通信连接的应用程序
使用隧道的好处：可以使用SSL进行加密
隧道是透明度的（本身不会解析HTTP请求），会在双方通信断开连接时结束。
缓存服务器
缓存服务器转发源服务器的响应时，会保存一份副本，可以避免多次向源服务器转发请求
缓存服务器会因为客户端要求、缓存的有效期等因素，向源服务器确认资源的有效性
客户端缓存
缓存可以留存在客户端浏览器中，如果浏览器缓存有效，就不用再向服务器请求资源了
过期会请求新资源
第六章 HTTP首部（响应头、请求头）
请求报文首部组成：请求行（URI，请求方法，HTTP协议版本）+ HTTP首部字段
响应报文组成：状态行（HTTP协议版本，状态码，描述语） + HTTP首部字段
首部字段结构：
首部字段名：字段值，
首部字段名：字段值1， 字段值2
首部字段分为两种：
- 端到端首部字段（End-to-end Header）：发送给请求/响应的最终目标，会被缓存，发送时携带
- 逐跳首部（Hop-by-hop Header）：只对单次转发有效，会因通过代理或缓存而不再转发
除了8个字段外(Connection/Keep-Alive/Upgrade等）是逐跳首部外，其余都是端到端首部：
通用首部字段
请求头和响应头都会使用
Cache-Control
可能取值：
public：缓存在用户间是共享的private：缓存只针对特定用户no-cache：缓存会在向源服务器确认后再被确定是否使用no-store：不缓存s-magAge：适用于供多位用户使用的公共缓存服务器（CDN），对同一用户重复返回响应的服务器来说无效，优先级高于max-age和Expiresmax-age：判定资源的有效期，为0时不缓存资源，优先级高于Expriesmin-fresh：返回指定时间内不会过期的资源max-stale：可接受的过期的缓存资源的期限，未指定参数则全部接受only-if-cached：只接受在缓存服务器缓存过的目标资源must-revalidate：代理向源服务器再次验证即将返回的响应资源是否仍然有效
Connection
Hop-by-hop首部
有两个作用：
（1）指明代理不再继续转发的字段：
Connection: 不再转发的首部字段名
（2）管理持久连接
当响应头返回Connection: close时，表明服务器要求断开持久连接
当请求头携带Connection: Keep-Alive时，表明客户端想要建立持久链接：
a.com GET HTTP/1.1
Connection: Keep-Alive
此时服务端应返回下面内容，建立持久连接
HTTP/1.1 200 OK
Keep-Alive: timeout=10, max=500
Connection: Keep-Alive
Date
表明报文创建的日期和时间
Date: Tue, 18 Dec 2018 02:48:05 GMT
GMT是格林尼治标准时间，是本初子午线上的覅昂是，比北京时间（东八区）晚8小时，所以北京时间需要在GMT时间的基础上+8
Pragma
历史遗留字段，与Cache-Control作用相同，一般为了兼容性考虑会同时存在：
Cache-Control: no-cache
Pragma: no-cache
Transfer-Encoding
规定了报文主体传输使用的编码方式
Transfer-encoding: chunked
HTTP/1.1只支持分块编码传输
Upgrade
这是一个逐跳字段，用来检测是否可以使用更高版本的协议，其参数值可以指定一个完全不同的协议
请求头：
/index.html GET HTTP/1.1
Upgrade: Websocket
Connection: Upgrade
因为Upgrade首部字段产生作用的对象仅限于客户端和邻接服务器支架，所以需要使用Connection指明Upgrade字段不再继续传递
响应头：
HTTP/1.1 101 Switching Protocols
Upgrade: Websocket
Connection: Upgrade
响应头对于头字段有Upgrade的请求，可以用101 Switching Protocols作为响应
Via
使用Via的目的是为了追踪客户端和服务器之间请求和响应报文的传输路径，常和trace方法一起使用
每经过一个代理服务器或者网关时，就会在Via中添加该服务器的信息，然后再进行转发
还可以避免请求回环
Waring
用来告知用户一些与缓存相关的警告
请求首部字段（请求头）
Accept
告知服务器，客户端可以处理的资源的类型，及其优先级
Accept: text/plain, text/html; q=0.9, appliaction/xml; q=0.8
用q来表示对应的类型的优先级权重，用;分割，默认权重为1, 取值范围是0-1
当服务器提供多种内容时，优先返回权重高的类型
Accept-Charset
通知服务器客户端支持的字符集和字符集的权重，用于服务器驱动协商。
Accept-Charset: ios-8859-5, unicode-1-1; q=0.9
Accept-Encooding
通知服务器客户端支持的内容压缩编码格式及其权重，常用的格式又gzip，也可以设置为*，指定任意编码格式。
有一个新的压缩算法：Brotli，简写br
accept-encoding: gzip, deflate, br
Accept-Language
通知服务器客户端能够处理的自然语言集（中文、英文等）及权重
Accept-Language: zh-cn, zh;q=0.7, en-us;0.3
Authorization
当客户端收到服务端401的响应后，会加入Authoriztion字段，提供用户代理的认证信息
Authoriztion: Basic dWdflkjfelkjsdfZA==
Host
一台服务器通过虚拟主机技术，提供了多个域名的托管服务，这些域名共用同一个IP，所以需要在请求头内使用Host字段区分所请求资源的互联网主机名和端口号
Host是HTTP/1.1唯一一个必须包含在内的首部字段。
如果服务器未设定主机名，直接发送空值即可。
Host: www.oldzhou.cn
Host:
If-Match
If-xxx这种形式的请求首部字段，都成为条件请求。服务器接收到附带条件的请求后，只有判断条件为真时，才会执行请求。
If-Match比对的是ETag，只有If-Match和ETag一致时才会执行请求，否则返回状态码412 Precondition Failed
用*指定If-Match的值，服务器会忽略ETag的值。
If-None-Match
与If-Match作用相反，只有当字段值与ETag不一致时才会执行请求。
在GET和HEAD方法中使用此字段，可以验证服务器内容相对于缓存是否有更新，是否继续使用缓存，可以获取最新资源。
If-Modified-Since
此字段指定一个日期，如果在这个日期后，资源发生了改变，服务器就会接受请求，返回最新资源。
如果资源在此日期后，未发生改变，服务器返回304 Not Modified
这个字段根据响应头中给出的Last Modified字段取值
If-Unmodified-Since
与If-Modified-Since作用相反，在给定的日期后资源未发生更新，服务器才会受理请求，否则返回状态码412 Precondition Failed
If-Range
If-Range中定义的字段（ETag或日期）与服务器的一致，则将这个请求作为范围请求处理，否则返回全部资源
If-Range: 123456
Range: 5000-6000
比使用If-Match节省一次请求
Max-Forwards
通过OPTION或TRACE发送请求时，Max-Forwards代表在代理服务器传递的最大步数，每经过一个代理服务器就减一，当减为0时服务器不再进行转发，直接返回响应
通过这个字段，可以探测在传输途径的通信状况。
Proxy-Authoriztion
和Authoriztion类似，区别是Proxy-Authoriztion用于客户端与代理之间的认证行为
Range
用于范围请求，表示请求资源的范围，服务器支持的话会返回216 Partial Content和对应范围的资源，不支持的话会返回200 OK和全部资源
Referer
告知服务器请求的URI是从哪个页面发起的。
Referer: https://weibo.com/zhouhaozhouhao/home?wvr=5
由于原始资源的URI的查询字符串中可能带有一些敏感信息，如果写进referer转发给其他服务器，可能带来安全问题。
例如，在网页中有一个链接，打开baidu.com
<a href="http://www.baidu.com/">click</a>
点击之后页面会跳转到百度的页面，这个时候看发出的请求百度页面的请求头，里面有referer字段，表明请求是从我们之前页面发出的：
如果在之前的链接增加rel="noreferrer"属性，就会将这个字段隐藏：
<a href="http://www.baidu.com/ rel="noreferrer"">click</a>
再看网络请求：
这样就可以避免不经意间通过referer泄露敏感信息。
同样，由于在新窗口打开页面时，新页面可以通过window.opener访问到源页面的widnow属性，通过window.location实现源页面的跳转等非法操作，也可以通过在连接上添加rel=noopener来将window.opener置为null（rel="noreferrer"属性也可以实现）
rel中还有一个属性nofollow，用于告诉搜索引擎不要追踪特定的网页链接
TE
TE用来指定传输编码及其优先级权重，和Accept-Enconding很像，后者是用来指定客户端可以接受的内容编码
TE: gzip, defalte;q=0.5
User-Agent
将创建请求的浏览器和用户代理的名称通过这个字段传给服务器
user-agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36
首部响应字段（响应头）
Accept-Ranges
与请求头中的Ranges对应，用来告知客户端服务器是否支持范围请求：
Accept-Ranges: bytes
Accept-Ranges: none
Age
告之客户端，源服务器在多久之前创建了响应，单位为秒
如果创建响应的是缓存服务器（CDN），代表缓存在多久之前向服务器确认过。
age: 699
ETag
服务器对资源用字符串做出的唯一性标识，当资源更新时ETag也会更新，生成算法由服务器自行确定。
etag: W/"5c10c31c-2e49b"
资源被缓存时，就会被非配唯一性标识。
ETag分为强ETag值和弱ETag值：
强ETag值无论实体发生多么细微的变化都会改变其值
etag: "580bc53ce99bb5ca6ca39616335ab612"
弱ETag值只用于提示资源是否相同，只有资源发生了根本改变，ETag才会改变，会在字段开始处附加W/
etag: W/"5c10c31c-2e49b"
Location
将客户端引导请求Location字段的URI的资源，配合3XX重定向使用，客户端在收到包含Location的响应头后，会强制性尝试对重定向的资源的访问
Proxy-Authenticate
会把由代理服务器要求的认证信息发送给客户端
Retry-After
告知客户端，在多久后再来访问资源，配合503 Service Unavailable或者3xx Redirect使用，取值可以使秒数，也可以是一个日期
Retry-After: 500
Retry-After: Wed, 19 Dec 2018 08:59:38 GMT
Server
告知客户端服务器上安装的提供HTTP服务的应用程序名：
Server: ZWS
Server: Apache
Server: nginx/1.14.0 (Ubuntu)
Vary
用来对缓存进行控制，代理服务器收到包含Vary指定项的响应后，只对请求中含有Vary指定首部相同字段的请求返回缓存，否则都必须要从服务器获取资源
Vary: Accept-Encoding
Vary: Accept-Language
WWW-Authenticate
用于HTTP访问验证
实体首部字段
请求头和响应头中都含有与实体有关的首部字段
Allow
通知客户端可以支持的HTTP方法
Allow: GET, HEAD
Content-Enconding
告知客户端服务器对实体的主体部分选用的内容编码方式
主要采用四种：
- gzip
- compress
- defalte
- identity
- br
Content-Language
实体使用的自然语言
Content-Length
实体主体部分的大小，主体使用内容编码传输时，不能在使用这个字段
content-length: 87537
Content-Location
返回的报文主体对应的URI（访问http://www.baidu.com，返回对象却是http://www.baidu.com/index.html的情况）
Content-Range
针对范围请求，告知客户端返回影响的实体的哪个部分符合范围请求
Content-Range: bytes 5001-10000/10000
Content-Type
与请求头中的Accept类似，说明实体内对象的媒体类型：
content-type: text/html; charset=utf-8
content-type: image/jpeg
Expries
告知客户端缓存的失效日期。
如果不希望进行缓存，需要对Expires指定过期日期。
当Cache-Control中指定max-age时，max-age优先级更高
Last-Modified
指明资源最终修改时间，与请求头中If-modified-since配合使用
与cookie有关的首部字段
Set-Cookie，服务器通过响应头中管理客户端使用的cookiecookie：请求头中发给服务器的cookie
Set-Cookie
set-cookie: status=enable; path=/; domain=.zhihu.com; expires=Thu, 01 Jan 1970 00:00:00 GMT; httponly; sercure
expires：指定cookie的有效期，省略的话有效期维持在浏览器会话的时间段内max-age：在cookie失效之前需要经过的秒数path：指定cookie的发送范围的文件目录，domain：指定可以访问cookie的域名，注定主域名后，二级域名同样有效secure：限制Web页面仅在HTTPS安全链接时才可以发送cookie，省略时HTTP和HTTPS都可以httponly：令客户端的JavaScript无法获取cookie，目的是防止XSS对cookie信息的窃取
注意：Set-Cookie的Expires和max-age，与响应头中的Cache-Control中的max-age，以及Expirs不同，前者是对Cookie的有效期的设定，后两者是对缓存资源的有效期的设定
Cookie
Cookie: status=enable
客户端收到多个cookie时，也会同时发送多个cookie
其他首部字段
HTTP首部字段是可以自行扩展的，会出现一些非标准的首部字段
X-Frame-Options
属于响应头，用于控制网站内容在其他网站的Frame标签内显示的问题，主要目的是为了防止点击劫持
点击劫持：在正常的网页上方覆盖透明的目标网站，覆盖在正常的网页上，诱导用户点击
X-Frame-Options的取值有两个：
DENY，禁止所有页面机加载该页面SAMEORIGIN，仅同源域名下的页面可以加载当该页面
X-XSS-Protection
属于响应头，用于控制浏览器XSS防护机制，可以取值：
DNT
DNT（DO NOT TRACK）属于请求头，表示拒绝个人信息被收集
0同意被追踪1拒绝被追踪
更多的关于安全方面的自定义头部信息可以参考这个页面。
第七章 确保Web安全的HTTPS
HTTP的缺点
HTTP的一些缺点：
- 明文传输数据 – 容易被窃取
- 不对通信方的身份进行验证 – 容易被伪装
- 不对报文的完整性进行验证 – 容易被篡改
针对明文传输
针对铭文被传输容易被窃取的问题，主要采用加密的方式解决：
- 通信加密
- 内容加密
通信加密是指将HTTP与SSL（Security Socket Layer）与TLS（Transport Layer Security）配合使用，即HTTPS，建立安全通信线路，在这套线路上进行HTTP请求
通信加密是指对报文的实体内容加密，前提是要求客户端与服务器同时具备加密、解密机制。
针对身份验证
HTTP本身是一个很简单的协议，不会对通信双方的身份进行验证，无论是谁发送的请求都会进行相应，这就导致了以下的问题：
- 请求有可能被发送给伪装的服务器
- 发起请求的有可能的是伪装的客户端
- 发送请求的客户端是否是具有权限访问敏感内容的客户端（权限问题）
- 无法拒绝无意义的大量请求，导致了DOS攻击（Denial Of Service，拒绝服务攻击）
SSL可以解决身份验证的问题，它提供了证书的机制，由可信赖的第三方提供，颁发给受信任的服务器和客户端，来验证双方的身份。
如果身份不符合预期，就会断开连接。
SSL的验证分为单向验证和双向验证，只有双向验证才会验证客户端的身份
针对报文的完整性
HTTP协议无法验证报文的完整性，也就是说没有办法确认，发出的请求/响应和接受到的请求和响应前后是相同的。
在请求传输的过程中，攻击者可以拦截并篡改内容，这就是中间人攻击（MITM，Man-In-the-Middle attack）
可以通过HTTP生成数字签名或者MD5值来进行确认，但是需要客户端用户确认，浏览器无法自动验证，并且如果数字签名本身被篡改，用户也无能为力。
还是用使用HTTPS
HTTPS
HTTPS（HTTP Secure）是HTTP加上加密、认证和完整性保护
HTTPS不是一种新的协议，知识在HTTP通信接口部分用了SSL和TLS协议代替，也就是说在HTTP与TCP之间增加了SSL，HTTP与SSL通信，再由SSL与TCP通信。
SSL独立于HTTP，是现在应用最广的网络安全协议。
SSL
加密方式主要有两种：
- 共享密钥加密
- 公开密钥加密
共享密钥加密指的是加密、解密共用一个密钥，因此也叫对称密钥加密，它的问题是如果将密钥安全的发送给客户端，一旦密钥被窃取，加密也就没有意义了
SSL采用的公开密钥加密是非对称加密，使用了一对非对称的密钥，一个是公开密钥（public key），一个是私有秘钥（private key）。
发送密文的一方使用对方的公钥加密，对方收到机加密的信息后，使用自己的私钥解密。这样的好处是私钥不需要在网络发送，而公钥不必担心被窃取。
这是因为，使用公钥对密文解密，现在的技术是不现实的。
HTTPS采用了公开密钥加密和共享密钥加密公用的混合加密方式。
在建立安全链接之前（不能保证传输安全）的交换密钥环节，使用公开密钥加密，交换在稍后的共享加密中要使用的密钥，建立了安全连接后，在交换报文阶段，使用共享密钥机密
公开密钥加密算法比共享密钥加密复杂，处理速度慢
数字证书
公开密钥加密还有一个问题：如何证明服务器下发的公钥没有被替换？
可以通过数字证书认证机构（CA，Certificate Authority）颁发的公开密钥证书解决这个问题。
流程是这样：
- 浏览器会将CA的公开密钥事先内置到浏览器当中（避免了这个证书在传递中出现的问题）
- 服务器将自己的公开密钥提交给CA
- CA使用自己的私有秘钥向服务器的公开密码部署数字签名并颁发公钥证书
- 客户端拿到服务器的公钥后，会利用浏览器内置的CA的公开密钥去验证服务器的公钥证书的真实性
- 验证通过后，使用服务的公开密钥对报文加密后发送
- 服务器使用私钥对报文解密
简化一下：
graph TD
浏览器内置密钥-->服务器申请CA证书
服务器申请CA证书-->服务器给客户端下发带有证书的公钥
服务器给客户端下发带有证书的公钥-->客户端验证服务器公钥证书
客户端验证服务器公钥证书-->客户端使用服务器公钥加密报文
客户端使用服务器公钥加密报文-->服务器使用私钥加密
客户端证书
在前面提到的双向验证中，服务器需要对客户端进行验证，就要利用客户端证书，证明服务器在通信的对方是预料之内的客户端
但是客户端证书安装有一定技术复杂度，并且需要付费，所以仅仅在安全等级要求高的场合使用，例如网银的一些列操作过程中，不仅需要输入密码，还要求用户的客户端证书
客户端证书仅能证明客户端实际存在，但无法证明用户本人的真实有效，一旦获得了安装证书的用户计算机的使用权限，也就意味着有了客户端证书的权限。
自签名证书
使用OpenSSL开源程序，每个人都可以构建一套属属于自己的认证机构，从而自己给自己的服务器办法证书，但这个证书在互联网上没有卵用，因为它没有办法消除伪装的可能性（自己对外宣称自己是XXX）
HTTPS通信步骤
- 客户端发送报文Client Hello开始SSL通信
- 服务器进行应答Server Hello，开始SSL协商
- 服务器发送包含公开密钥的Certificate报文
- 服务器发送Server Hello Done，通知客户端最初阶段的SSL协商
- 客户端发送报文Client Key Exchange，包含随机密码串，报文已通过公钥加密
- 客户端发送Chnage Cipher Spec报文，提示服务器此后的报文会采用刚刚发送的随机密码串加密
- 客户端发送Finished报文
- 服务器同样发送Client Key Exchange报文
- 服务器同样发送Finished报文
- 服务器和客户单的Finished报文交换完毕后，SSL建立成功，开始应用层通信，发送HTTP请求
应用层发送数据时会附加MAC（Message Authentication Code）的报文摘要，查知报文是否遭到篡改，保护报文完整性
TLS
TLS是以SSL为原型开发的协议，有时会统一称为SSL，当前主流版本是SSL3.0和TLS1.0
HTTPS导致速度变慢
HTTPS会导致通信速度和处理速度变慢
通信速度边忙是因为要进行SSL的通信，处理速度变慢是因为SSL进行的加解密运算处理，会消耗更多的硬件资源，导致负载增强。
针对速度变慢，没有根本性的解决方案
因为性能的影响和购买证书的开销，所以应该是非敏感信息应使用HTTP通信，只有在包含个人信息等敏感数据时，采利用HTTPS通信。
第八章 确认访问用户身份的认证
认证核对的方式通常包括：
- 密码
- 数字证书
- 动态令牌
- 生物认证
- IC卡
HTTP/1.1使用的认证方式包括：
- BASIC认证（基本认证）
- DIGEST认证（摘要认证）
- SSL客户端认证
- FormBase认证（基于表单认证）
BASIC认证
HTTP/1.0就使用的认证方式，步骤如下：
- 客户端发送GET请求
- 服务度返回
401 Authorization Required，和WWW-Authenticate: Basic real="asdf"的响应头，要求客户端进行BASIC认证 - 客户端收到
401响应后，需要将用户名和密码用:连接，经过Base64编码处理，在Authorization中发送给服务端（浏览器可以提供对话框，填入用户名密码） - 服务器接收到带有首部字段
Authorization的请求，对认证信息进行验证。
这个过程是一种质询/响应（challenge/response）式的认证方式，一方开始发送认证要求给另一方，接着使用从另一方接受到的质询码后生成响应码，将响应吗返回给对方。
BASIC的问题：
- 用户名和密码经过Base64编码后明文传输，容易窃取
- 无法注销
所以基本没人用
DIGEST认证
DEGEST认证也是质询/响应式的认证方式，但发送给对方的只是响应摘要和质询码产生的计算结果，不会明文传输密码。
DIGEST比BASIC强一点，但也不能阻止用户伪装，所以基本也没人用
SSL客户端认证
SSL客户端认证是借由HTTPS的客户端证书完成认证的方式。
采用了双因素认证，不仅需要密码（确定是用户本人的行为），还需要申请认证者提供其他申请信息（用SSL客户端证书认证客户端计算机）
SSL客户端需要支付费用，还需要进行导入，所以也没人用。
基于表单认证
基于表单的认证方法不是HTTP协议中定义的，客户端会向服务器上的Web应用程序发送登陆信息，按登陆信息的验证结果认证
基于表单认证各有实现，没有标准，一般会使用cookie管理session
因为HTTP是无状态协议，无法实现状态管理，当用户下一次访问，也无法区分他与其他用户，所以用cookie管理session，实现状态管理
流程：
（1）客户端将用户名密码放在报文的实体部分，用POST方法将请求（一般通过HTTPS通信）发送给服务器
（2）服务器验证通过后，发放识别用户的SessionID，将用户的认证状态与SessionID绑定后记录在服务器端，同时通过Set-Cookie写入SessionID
SessionID如果被盗走，对方就可以伪装成为用户身份进行恶意操作了，所以需要将SessionID设定为难以推测的字符，并进行有效期管理。
（3）客户端收到SessionID后，会作为cookie保存在本地，下发请求会自动将存有SessionID的cookie发送给服务器。
（4）服务器再次收到请求后，通过SessionID识别用户及其认证状态
第九章 基于HTTP的功能追加协议
HTTP的瓶颈
- 一条连接上只可以发发送一个请求（keep-alive呢？）
- 请求只能从客户端开始，服务器不能推送
- 请求头、响应头未经压缩
- 请求头、响应头冗长，浪费
- 非强制压缩发送数据
Comet
就是长轮询，用来模拟服务器推送，当服务器收到客户端的请求，如果内容没有更新不会立即返回内容，而是将响应处于挂起状态，当内容更新时再返回该响应
虽然可以做到实时更新，但是因为要保留连接，一次响应的持续时间变长，维护连接会消耗资源。
SPDY
SPDY（speedy）是2010年Google发布的，在应用层和传输层之间增加了会话层，强制使用SSL。
SPDY带来的：
- TCP连接的复用，一个TCP连接可以处理多个HTTP请求
- 赐予请求优先级
- 压缩HTTP首部
- 服务器推送（推送的是文件，而非数据）
- 默认使用HTTPS
由于SPDY只是将单个域名（IP地址）的通信多路复用，而当一个Web网站使用多个域名下的资源，改善效果会打折扣
WebSocket
Websocket是客户端与服务器之间的全双工通信标准。
一旦Websocket协议的通信连接建立，客户端和服务器之间可以互相发送JSON、HTML、XML、图片等任意格式的数据
Websocket具有的功能：
- 服务端推送（可以推送数据）
- 减少通信量（减少了连接次数，并且首部信息很少）
Websocket是基于HTTP的，所以连接的发起方仍是客户端，需要完成一次握手过程，需要用到请求头中的Upgrade字段
GET /chat HTTP/1.1
Upgrade: Websocke;
Connnection: Upgrade
服务器会返回101的响应：
HTTP/1.1 101 Switching Protocols
Upgrade: Websocke;
Connnection: Upgrade
握手成功后，通信不再使用HTTP的数据帧，使用Websocket独立的数据帧
Websocket API
JavaScript可以调用Websocket API，实现全双工通信
const socket = new Websocket('ws://game.example.cpm:10201/u');
socket.open = function () {
socket.send('123')
}
HTTP/2.0
- 在HTTPS协议基础上实现（支持HTTP传输，SPDY强制使用HTTPS）
- 使用二进制格式进行传输（HTTP1.x的解析是基于文本)，适用性更强
- 可以复用TCP连接，多个HTTP请求放在一个连接中进行
- HEAD压缩（只有新增或变更时才传输）
- 服务器推送
WebDAV
WebDAV是一个可以对Web服务器上内容进行文件复制、编辑等操作的分布式文件系统，是HTTP的扩展
是本地引用网络中储存空间的一种办法
第十章 构建Web内容的技术
略
第十一章 Web的攻击技术
在HTTP请求报文内加载攻击代码，就能发起对Web应用的攻击，通过URL查询字段或表单、HTTP首部、Cookie等途径把攻击代码传入，从而窃取内部信息或者获得管理权限。
Web应用的攻击模式有两种：
- 针对服务器的主动攻击，直接访问Web应用，把攻击代码传入，代表性的有SQL注入和OS命令注入
- 针对服务器的被动攻击，不直接对目标Web应用发起攻击，诱导用户访问内嵌攻击代码的网页，从而将含有攻击代码的HTTP请求发送给Web应用，运行攻击代码，代表性的有跨站脚本攻击和跨站伪造请求攻击
对输出值进行转义
安全对策分为两个部分：
- 客户端验证
- 服务器端验证：输入值验证，输出值转义
跨站脚本攻击
跨站脚本攻击（XSS, Cross Site Scripting）是指存在安全漏洞的网页上运行非法的HTML标签或者JavaScript代码
也就是页面被注入了恶意代码，XSS的本质是：恶意代码未经过滤，与网站正常的代码混在一起；浏览器无法分辨哪些脚本是可信的，导致恶意脚本被执行。
XSS常见的注入的方法
在处理输入时，以下内容都不可信：
- 来自用户的UGC（用户原创内容）信息
- 来自第三方的链接
- URL参数
- POST参数
- Referer （可能来自不可信的来源）
- Cookie （可能来自其他子域注入）
SQL注入攻击
SQL是针对Web应用的数据库，通过运行非法的SQL产生的攻击，攻击者将SQL语句改变成为开发者意想不到的形式以达到破坏结构的攻击。
OS命令注入攻击
OS命令注入攻击值是通过Web应用执行非法的操作系统命令，达到攻击的目的
只要能调用Shell函数的额地方就存在被攻击的风险。
HTTP首部注入攻击
是指攻击者通过在响应首部字段内插入换行，添加任意响应首部或主题的攻击（响应截断攻击）
实现方法是：如果服务器从URL中获取参数，添加到响应头的字段时，就可以通过添加换行，从而添加任意头字段，随意设置COokie信息，重定向到任意URI，显示任意的主题
会话劫持
是指攻击者通过某种手段拿到了用户的会话ID，并非法使用此会话ID伪装成用户，达到攻击目的
会话固定攻击
强制用户使用攻击者指定的会话ID
跨站伪造请求攻击
跨站伪造请求（Cross-Site Request Forgeries， CSRF），是指攻击者通过设置好的陷阱，诱导已登录（已认证）的用户访问，执行恶意代码，从而借用用户权限执行某些特定行为
点击劫持
是指利用透明的按钮或链接做成陷阱，覆盖在Web页面之上，诱使用户在不知情的情况下点击链接访问内容的攻击手段。
DoS攻击
DoS攻击（Denial of Service）是一种让运行中的服务停止状态的攻击，也就做拒绝服务攻击
有两种方式：
- 集中利用访问请求造成资源过载（发送大量的合法请求，服务器来不及处理）
- 攻击安全漏洞是服务停止
2011
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
