1. TCP/IP分层

TCP/IP协议族分为四层：应用层、传输层、网络层和数据链路层。OSI模型将网络通信分为七层：应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。

利用TCP/IP协议族进行网络通信时，会通过分层顺序与对方进行通信。发送端从应用层往下走，接收端则往应用层往上走。
发送端的客户端在应用层（HTTP协议)发送一个想看到某个Web页面的Http请求。在传输层（TCP协议）把应用层处接收到的数据（HTTP请求报文）进行分割，并将各个报文打上标记序号及端口号后转发给网络层。在网络层(IP协议)，增加作为通信目的地的MAC 地址后转发给链路层，直至发送到接收端服务器。接收端服务器接收到数据，按序往上层发送，一直到应用层。

发送端在层与层传输数据时，每经过一层必定打上一个该层所属的首部信息，例如http首部，TCP 首部，ip首部，以太网首部。接收端在层与层传输数据时，每经过一层会将对应的首部消掉。

IP 地址指明了节点被分配的地址，MAC 地址是指网卡所属固定的地址。IP地址可以与MAC 地址进行配对。IP 地址可变换，但是MAC 地址基本上不会更改

使用ARP协议凭借MAC地址进行通信。

2. TCP 三次握手

为准确无误的将数据送达目标处，TCP 协议采用三次握手策略。握手过程使用TCP标志（flag)-SYN(synchronize)和ACK(acknowledgement)。发送端首先发送一个带有SYN标志的数据包给对方。接收到后回传一个带有SYN/ACK标志的数据包以示传达确认信息。最后发送端再回传一个带有ACK标志的数据包，代表“握手”结束。

3. URI

URI(统一资源标识符)用字符串标识某一互联网资源，而
URL(统一资源定位符)表示资源的地点（互联网上所处的位置）。可见URL是URI的子集。

4. HTTP报文

1. 请求报文是有请求方法、请求URL、协议版本、可选的请求首部字段 和内容实体构成。
2. 响应报文是有协议版本号、状态码、状态码原因短语、可选的响应首部字段以及实体主体构成。
3. Http 是一种不保存状态的协议,可通过cookie实现状态管理
4. HTTP 报文不一定有报文主体，例如HEAD 方法返回的报文。
5. HTTP 报文本身是有多行（CR+LF作为换行符）数据构成的字符串文本。 可以分为报文首部，及报文主体

5. 提高HTTP 效率

HTTP协议初始版本中，每进行一次HTTP通信就要断开一次TCP连接，协议后来提高效率方式有

1. 持久连接，减少TCP重复建立和断开所造成的额外开销，减少服务器负载，提高响应效率。
2. 管线化。HTTP 初始版本，发送请求需等待并受到响应，才能发送下个请求。管线化后可不用等待，可同时并发多个请求。

HTTP/1.1 所以连接默认都是持久连接。但在HTTP/1.0内并未标准化。

6. 状态码

• 1XX,信息性状态码，接受请求正在处理
• 2XX，成功状态码，请求正常处理完毕
• 3XX, 重定向状态码，需要进行附加操作以完成请求
• 4XX,客户端错误状态码，服务器无法处理请求
• 5XX,服务器错误状态码，服务器处理请求出
• 301：永久重定向，表示该请求资源已被分配了新的URL,以后应使用资源现在所指定的URI。
• 302：临时性重定向，表示请求资源已被分配新的URL,希望用户本次能使用新的URI访问。
• 301、302标准是禁止将POST方法改变成GET方法

7、 首部

1. 当首部重复，目前规范尚未明确，不同浏览器处理逻辑各部相同。
2. 客户端请求首部包含Cache-Control：no-cache,则表明客户端将不会接受缓存过的响应，于是中间的缓存服务器必须将客户端请求转发给源服务器。
3. 客户端请求头包含max-age指令，如果判定缓存资源缓存时间数比指定数值更小，那么客户端就接受缓存资源。当指定max-age为0，那么缓存服务器通常需要将请求转发给源服务器。
4. HTTP/1.1版本缓存服务器遇到Expires首部及max-age指令，会忽略掉Expires首部，而HTTP/1.0版本相反，max-age指令会被忽略掉。
5. HTTP/1.1版本默认是持久连接。当服务器想明确断开连接时，则指定Connction 首部字段值为Close。而之前HTTP协议版本默认都是非持久化连接。如果希望在旧版本HTTP协议维持持久化连接，则指定Connecton首部字段值为Keep-Alive.
6. 首部字段Upgrade 用于升级协议版本。使用首部Upgrade时，还需要额外指定Connection:Upgrade。
7. 首部字段Host会告知服务器，请求资源所处的互联网主机名和端口号。Host是HTTP/1.1规范中唯一一个必须被包含在请求内的首部字段。Host 在单台服务器，分配多个域名虚拟主机。用 来明确指出请求主机名。

8. Cookie

1. 服务器通过Set-Cookie首部控制cookie,包含NAME=VALUE、expires=DATE、path=PATH、domain=域名、Secure、HttpOnly
2. 当省略expires属性，其Cookie有效期及限于维持浏览器会话（Session)时间段内。这通常限于浏览器应用被关闭之前。
3. 添加secure属性用于限制Web页面仅在Https安全连接时，才可以发送Cookie.
4. HttpOnly属性使Cookie不能被JavaScript脚本访问，主要目的为防止跨站脚本攻击（XSS)对Cookie信息的窃取。
5. 一旦Cookie 从服务器发送给客户端，服务端就不存在可以显示删除Cookie的方法，但是可以通过覆盖已过期Cookie,实现对客户端Cookie实质性删除操作。

9. HTTP缺点

• 无状态协议
• 通信使用明文（不加密），内容可能会被窃听（窃听风险）
• 不验证通信放身份，因此有可能遭遇伪装（冒充风险）
• 无法验证报文完整性，英雌可能已遭篡改。（篡改风险）

10.HTTPS

• Https是身披SSL外壳的HTTP,并非是应用层的一种新协议，只是Http通信接口部分用SSL(Secure Socket Layer)和TLS(Transport Layer Security)协议代替而已。通常HTTP直接和TCP通信，当时用SSL时，则演变成先和SSL通信，再由SSL和TCP通信。
• 采用SSL 后，HTTP拥有HTTPS的加密、证书和完整性保护。
• SSL 时独立于HTTP的协议，其他应用层的协议均可配合SSL协议使用
• HTTPS使用SSL和TLS这两个协议，TLS是以SSL为原型开发的协议，有时统称SSL。当前主流为SSL3.0和TLS1.0
• HTTPS 采用共享密钥加密（对称密钥加密）和公开密钥加密（不对称密钥加密）两者并用混合加密机制。交换密钥环节使用公开密钥加密方式，之后建立通信交换报文阶段则使用共享密钥加密方式。
• 公开密码加密通信存在无法证明公开密钥就是货真价实的公开密钥。可使用数字证书认证机构和其他相关机构颁发的公开证书。
• 整个SSL握手阶段都不加密（也没法加密），都是明文的。建立SSL连接采用对称加密报文。

11. HTTPS 缺点

• 证书成本
• 降低访问速度（多次握手）
• 改造HTTPS后，之前HTTP 跳转到 HTTPS 的方式增加了用户访问耗时（多数网站采用302跳转）
• HTTPS 涉及到的安全算法会消耗 CPU 资源

12. HTTPs 为啥能安全通信

SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密

• 保证公钥不必篡改：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的
• 减少公钥加密时间： 非对称公钥只用于SSL 握手阶段加密"对话密钥"本身，建立SSL连接后，通过对称密钥加密报文，减少非对称密码加密解密耗时。
• SSL/TLS协议的基本过程：
  • 客户端向服务器索要并验证公钥
  • 双方协商对话密码
  • 双方采用对话密码进行加密通信。

13. HTTPS 通信过程

1. 客户端通过发送CLient Hello 报文开始SSL 通信，报文中包含客户端支持的SSL版本、加密算法、支持压缩方法、生成随机数。
2. 服务器可进行SSL通信时，会以Server Hello报文作为应答。在报文中确认通信SSL协议、加密方法 及生成的随机数，稍后用于生成"对话密钥"
3. 之后服务器发送Cerficate报文，报文包含公开密钥证书
4. 最后服务器发送Server Hello Done 报文通知客户端，最初SSL 握手协商部分结束
5. 客户端收到证书后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信，客户端以Client Key Exchange报文作为回应，报文中包含通信加密中使用的Pre-master secret 随机密钥串。
6. 客户端继续发送Change Cipher Spec报文。提示服务，在此报文之后通信会采用Pre-master secret 密钥加密
7. 客户端发送Finished 报文。报文包含连接至今全部报文的全体校验值。这次握手协商是否能成功，要以服务器是否能够正确解密该报文作为判断标准
8. 服务器同样发送Change Cipher Spec 报文
9. 服务器同样发送Finished 报文
10. SSL 连接建立完成，通信受SSL保护，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用"会话密钥"加密内容。

14. 浏览器验证证书

• 浏览器读取服务器发送过来的证书，对证书所有者、有效期等信息进行一一校验，看是否过期等
• 浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发
• 如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的
• 如果找到，那么浏览器就会从操作系统中取出 颁发者CA 的公钥，然后对服务器发来的证书里面的签名进行解密
• 浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比
• 对比结果一致，则证明服务器发来的证书合法，没有被冒充
• 此时浏览器就可以读取证书中的公钥，用于后续加密了

15. HTTPS 升级操作

• 获取证书
• 安装证书 (证书可以放在/etc/ssl目录（Linux 系统）)
• 修改链接:因为加密网页内如果有非加密的资源，浏览器是不会加载那些资源的,需要将http链接改成Https链接）
• 301重定向：使用 301 重定向，将 HTTP 协议的访问导向 HTTPS 协议
• 参考：
  • HTTPS 升级指南

16. session 管理及认证过程

• 客户端将用户名和密码等登录信息放入报文实体部分提交给服务器。
• 服务器对客户端发送过来的登录信息进行身份验证，并生成识别用户的session ID,将用户身份信息及认证状态与Session绑定记录在服务端。向客户端返回响应，在首部字段Set-Cookie写入Session ID
• 客户端接受到从服务器发来的Session ID后，会将作为Cookie保存在本地。
• 客户端下次向服务器请求，浏览器自动发送Cookie,Session ID 也随之发送到服务器。
• 服务器通过验证接收到的Session ID识别用户和其认证状态。

17. HTTP 标准缺点

• 一条连接上只可发送一个请求
• 请求只能从客户端开始，客户端不可以接受除响应以外的指令
• 请求/响应首部未经压缩就发送。首部信息越多延迟越大
• 发送冗长的首部。每次互相发送相同的首部造成的浪费较多。
• 可任意选择数据压缩格式。非强制压缩发送

18. SPDY

• SPDY 没有完全改写HTTP 协议，而是在TCP/IP的应用于传输层之间通过新加的会话层形式运作。同时，考虑安全性问题，SPDY规定通信中使用SSL。SPDY 以会话层的形式加入，控制对数据的流动，但还是采用HTTP 建立通信连接。
• 优点：
  • 多路复用
  • 赋予请求优先级
  • 压缩HTTP 首部
  • 推送功能
  • 服务器提示功能

19. Websocket

• WebSocket通过Http建立连接，然后升级到WebSocket协议，之后所有的通信都依靠这个专门的协议进行。
• 与HTTP相比，Websocket连接建立后就希望一直保持连接状态，减少每次连接开销，而且Websocket首部信息很小，通信量也减少。

20. 网络攻击

• 因输出值转义不完全引发安全漏洞
  • 跨站脚本攻击（XSS)
  • SQL注入（SQL injection)
  • OS命令注入攻击（OS Command Injection)
  • HTTP首部注入攻击（HTTP Header Injection)
  • 邮件首部注入攻击（Mail Header Injection)
  • 目录遍历攻击（Directory Traversal)
  • 远程文件包含漏洞
• 设计上缺陷导致安全漏洞
  • 强制浏览
  • 不正确的错误消息处理
  • 开放重定向
• 会话管理疏忽引发安全漏洞
  • 会话劫持（Session Hijack)
  • 会话固定攻击
  • 跨站点请求伪造（CSRF)
• 其他安全漏洞
  • 密码破解
  • 点击劫持（Clickjacking)
  • DoS攻击（Denial of Service attack)
  • 后门程序