基础

架构

OSI模型

1. 应用层

2. 表示层

3. 会话层

4. 传输层

5. 网络层

6. 数据链路层

7. 物理层

TCP/IP模型

1. 应用层

2. 传输层

3. 网络层

4. 网络接口层

传输层

为应用进程提供端到端的通信服务。

TCP协议

首部字段

前20个字节是固定的，且最小长度是20字节。

1. 进程端口号，包括源端口号+目的端口号（各占2字节

2. 序号（占4字节），本报文段所发送的第一个字节的序号。

3. 确认号（占4字节），期望收到对方下一个报文段的第一个字节的序号。

4. 数据偏移（占4字节），指明TCP报文首部长度。

5. 校验和

6. 窗口（占2字节）

7. 标志位

8. 选项

特点

1. 面向连接的协议。

2. 每一条TCP连接都是点对点的。

3. 提供可靠交付的服务。

4. 提供全双工通信。

5. 面向字节流

可靠传输是怎么保证的？通过确认+超时重传实现。

流量控制

通过滑动窗口的实现。目的是使发送方的发送速率不要太快，让接收方来得及接收。

拥塞控制

防止过多的数据注入到网络中，避免网络中的路由器和链路过载。

2个重要的参数

1. 拥塞窗口大小cwnd

2. 慢开始门限ssthresh

慢开始&拥塞避免

为了便于理解，窗口的单位不使用字节而是报文段的个数。

所谓慢开始就是逐步试探网络拥塞程度。当cwnd<ssthresh时，每一个传输轮次结束后，cwnd = cwnd * 2。

当cwnd > ssthresh时，启动拥塞避免策略，即每一个传输轮次结束后，cwnd = cwnd + 1。

当网络出现拥塞时，即出现超时的现象时，ssthresh = cwnd/2; cwnd = 1;。继续从慢开始启动。

快重传&快恢复

导致超时的原因可能是：

1. 拥塞导致的超时

2. 报文丢失导致的超时->快重传+快恢复

快重传就是为了让发送方尽早知道个别报文段的丢失。做法：接收方立即再次发送对上个收到的报文段的确认，并发送3次。当发送方只要连续收到3个重复确认，就立即进行重传。

发送方发现超时不是拥塞造成时，启用快恢复而非慢开始，即ssthresh = cwnd /2，同时设置cwnd=ssthresh，启用拥塞避免算法。

连接管理

用于保证可靠性和流控制机制的信息，包括 Socket、序列号以及窗口大小叫做连接。

三次握手

1. 客户端向服务端发送同步报文段SYN = 1, seq = x（客户端进入同步发送状态）

2. 服务端收到后向客户端发送确认报文段ACK = 1, ack = x+1以及同步报文段SYN = 1, seq = y（服务段进入同步接收状态）

3. 客户端收到后，发送确认报文段ACK = 1， ack=y+1（客户端连接建立成功）

4. 服务端收到确认报文段（服务端连接建立成功）

注意同步报文段不携带任何数据，但消耗一个序号。

为什么是三次，而不是二次握手？

防止已失效的连接请求报文段突然又传到了服务端，发生错误。比如说先前C到S的同步报文段在网络中滞留了，在本次连接结束后又传给了服务端，这时如果没有第三次确认，服务端就建立连接等待客户端发送数据，从而造成资源浪费。

四次挥手

客户端C，服务端S

1. C向S发送终止报文段SYN=1, seq = u，C进入等待结束1

2. S收到后对C发送确认报文段ACK=1,ack=u+1,seq = v，S进入关闭等待状态

3. 此时C收到确认后，C到S的连接就断开了，C进入等待结束2

4. S对C发送终止报文段FIN=1, ACK=1, seq = w, ack = u+1，S进入最后确认状态

5. C对S发送确认报文段ACK=1, ack=w+1, seq=u+1，C经过2MSL时间进入关闭状态，因此S比C更早结束。

为什么要设置2MSL(最大报文段寿命)？

1. 确保最后一个确认报文段能够到达服务端

2. 防止已失效的连接请求报文段出现在本连接中

UDP协议

首部字段

只有8个字节

1. 目的、源端口号（各2字节）

2. 长度（2字节）

3. 检验和（2字节）

特点

1. 无连接的，减少开销和时延

2. 尽最大努力交付

3. 面向报文，即对应用程序交下来的报文不进行查分和合并。

4. 没有拥塞控制。

5. 支持一对一，一对多，多对多的通信。

6. 首部开销小，只有8字节。

网络层

IP协议

首部字段

首部前一部分是固定20字节，后一部分是可选字段，长度不固定。

1. 版本号

2. 目的，源IP地址

3. 总长度，首部长度

4. 片偏移

5. 首部检验和

应用层

提供分组转发和路由选择的功能，能够为上层提供在不同主机之间运输分组的职责。

DNS协议

HTTP协议

HTTP报文是由多行数据构成的字符串文本。

URL统一资源定位符，URI统一资源标识符，其中URL是URI的子集。

方法

1. GET：获取资源

2. POST：传输实体主题

3. DELETE：删除文件

4. PUT：传输文件

5. HEAD：获得报文首部

6. TRACE：追踪路径

7. CONNECT：要求用隧道协议连接代理

RESTFUL风格接口：根据方法和URL来就可以判断此次请求的行为是什么。

GET和POST的区别

1. 参数

2. GET幂等（即不会改变系统状态），POST不幂等

状态码

1. 2XX成功

   1. 200 OK

2. 3XX重定向

   1. 301 Move Permanently 资源已被分配了新的URI

   2. 302 Found 临时重定向

3. 4XX客服端错误

   1. 401 Unauthorized

   2. 403 Forbidden 无权访问

   3. 404 Not Found 无法找到资源

4. 5XX服务端错误

   1. 500 Internal Server Error 服务端存在bug

   2. 503 Service Unavailable 服务器处于超负载或停机维护无法提供服务。

报文首部

HTTP请求报文

1. 请求行

2. 请求首部字段：用于补充请求的附加信息、客户端信息、对响应内容相关的优先级等内容。比如Accept等。

3. 通用首部字段：比如Date字段；

4. 实体首部字段：用于补充内容的更新时间等与实体相关的信息。Content-type等

5. 其他

HTTP响应报文

1. 状态行

2. 响应首部字段：用于补充响应的附加信息、服务器信息，以及对客户端的附加要求等信息。

3. 通用首部字段

4. 实体首部字段

5. 其他

无状态连接

协议自身不对请求和响应之间的通信状态进行保存。

如何保存用户状态？

使用Cookie就可以管理状态了。

Cookie技术通过在请求和响应报文段中写入Cookie信息来控制客户端的状态。

Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的 首部字段信息，通知客户端保存 Cookie。当下次客户端再往该服务器 发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出 去。

服务器端发现客户端发送过来的 Cookie 后，会去检查究竟是从哪一 个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前 的状态信息。

1.0和1.1版本之间的区别

1. 长连接（客户端和服务端建立连接后不进行断开）和短连接

2. 错误状态码增多

3. 缓存处理

HTTPS协议

HTTP与HTTPS的区别

HTTP的缺点

1. 通信使用明文，不加密

2. 不验证通信方的身份

3. 无法证明报文的完整性

HTTPS = 加密+认证+完整性保护+HTTP

实现机制

目前已经使用TLS(传输层安全协议)取代了废弃的SSL（安全套接层），不过仍然使用SSL证书。

HTTPS采用混合加密机制

1. 对共享秘钥使用非对称加密传输

2. 对内容使用对称加密传输

保证公开秘钥的正确性：数字证书认证机构。客户端使用证书认证机构的公开秘钥对数字签名验证，验证成功说明服务器的公开密钥是真实有效的。

连接过程

通过TLS握手交换双方的秘钥。

1. C发送Client Hello消息开始TLS通信

2. 服务器向客户端发送certificate消息（服务端的证书链），ServerKeyExchange消息（传递公钥和签名）。

3. 客户端收到后验证服务端的证书，给服务端发送CLient Key Exchange（被服务端公钥加密的随机密码串），Change Cipher Spec（通知服务端后续数据的会加密传输）

4. 服务端收到消息后，向客户端发送Change Clipher Spec消息，通知客户端后面的数据段将加密传输

缺点

1. TLS协议会在TCP协议之上通过四次握手建立TLS连接，增加了时间开销

2. 证书需要购买

常见问题

浏览器输入URL之后的操作

1. 域名转化为IP地址（DNS协议）

2. 建立TCP连接

3. 客户端发送HTTP请求报文

4. 服务端发送HTTP响应报文

5. TCP断开连接