目录
基础知识
TCP/IP四层模型
| 层级名 | 主要内容 | 解决问题 |
|---|---|---|
| 应用层 | 主要包括HTTP、DHCP协议 | 解决数据与应用程序对接的问题 |
| 传输层 | 主要包括TCP、UDP协议 | 解决数据在端到端传输的可靠性问题 |
| 网络层 | 主要包括IP协议 | 解决数据包在单一网络中传输的问题 |
| 网络接口层 | 主要包括物理设备、以太网等 | 解决数据包从一个设备的网络层到另一个设备的网络层的问题 |
开发者需重点关注应用层和传输层知识。
UDP协议特点
- 无连接：不需要建立连接就可以传输数据
- 不可靠：不能确保数据完整送达
- 面向报文：不处理应用层发送过来的数据，直接封装进UDP数据报中
- 无拥塞控制：无视网络压力进行传输
- 头部开销小：仅由源端口号+目的端口号+数据长度+校验和共8字节组成
TCP协议特点
- 面向连接：双方需要经过三次手建立连接后方可通信
- 可靠传输：利用停止等待协议或连续ARQ协议确保数据准确无误的到达
- 面向字节流：应用程序的数据被看成一串可拆分的字节流
- 流量控制：利用滑动窗口协议感知接收方压力，实时控制流量
- 拥塞控制：发送方根据网络压力调整发送速度，防止堵塞网络
TCP的三次握手
| 标记 | 含义 |
|---|---|
| ACK | 确认位，ACK=1时确认号才生效 |
| SYN | 同步位，SYN=1时表示建立连接 |
| FIN | 终止位，FIN=1时表示释放连接 |
TCP的四次挥手
网络套接字
套接字是进程与进程间通信的端点，它由IP+端口组成。
通过套接字可以进行数据的发送和接收。
TCP连接由两个套接字组成。
HTTP协议特点
- 支持C/S模式：客户端向服务端发送请求，服务端向客户端发送响应
- 简单快速：客户端向服务器发送请求时，只需传输方法和路径
- 灵活：允许传输任意类型(Content-Type)的数据对象
- 无连接：限制每次连接只处理一个请求，响应结束后即断开
- 无状态：对于事务没有记忆能力，每次处理都需要重传全部所需的数据
HTTPS安全措施
- 对称加密：使用公钥加密和解密
- 非对称加密：使用公钥加密，使用私钥解密（公钥无法解密）
- 数字证书：可信任组织颁发给特定对象的认证（包含公钥）
- SSL：位于应用层和传输层之间，提供数据安全和数据完整服务
典型面试题
请简述TCP三次握手的过程
三次握手是为了建立连接。
第一次握手时，客户端会发送SYN包给服务端，并进入同步已发送状态，等待服务端确认；
第二次握手时，服务端收到数据包后对客户端的seq进行确认，并向客户端发送一个SYN+ACK包，并进入同步已接收状态，等待客户端确认；
第三次握手时，客户端收到数据包后对服务端的seq进行确认，并向服务端发送一个ACK包，至此三次握手完成。
为什么需要三次握手，两次不行吗？
从两个角度考量：
①初始化Sequence Number的值：TCP通信的双方需告知彼此的seq值，TCP协议会根据seq来拼接数据，从而避免数据乱序，只有三次握手才能确保双方收到了彼此的seq序号。
②防止已经失效的请求报文被对方打开：当客户端发送的SYN包长时间未得到服务端确认时将会发送新的SYN包，先前发出的请求报文会失效，如果两次握手就能建立连接，一旦服务端在之后应答了那些超时的请求，便会建立起错误的连接，只有三次握手才能确保失效的会话能够被客户端忽略。
请简述TCP四次挥手的过程
四次挥手是为了终止连接。
第一次挥手时，客户端会发送FIN包给服务端，并进入第一次完成等待态，等待服务端确认。
第二次挥手时，服务端收到数据包后对客户端的seq进行确认，并向客户端发送一个ACK包。此时服务端将进入关闭等待态，只能发送数据，但已不再接收数据；而客户端将进入第二次完成等待态，只接收数据，不再发送数据。
第三次挥手时，服务端发送FIN包给客户端，进入最后确认状态。
第四次挥手时，客户端会对服务端发送的终止连接的seq进行确认，并回复一个ACK包。为确保确认报文能顺利送达，客户端会开启一个等待计时器，默认等待2MSL(2倍最大分段寿命)才关闭连接，而服务端一旦收到确认报文就会立刻关闭连接。
为什么断开连接需要四次握手？
因为TCP协议是全双工协议，若需断开连接，双方均需发送一次FIN报文并获取ACK报文，故总共发生了4次握手
四次挥手为什么有TIME-WAIT状态
①确保有足够的时间让对方收到ACK包：在等待时间内，若被动关闭端长时间未收到主动关闭端的ACK包，那么会触发超时重传。
②避免新旧连接混淆：2MSL对应数据包一来一回的最大时长，等待2MSL可以让网络中的所有旧报文都失效，这样在下次建立TCP连接时不会受到超时报文的影响。
服务器出现大量CLOSE-WAIT状态的原因？
客户端发送FIN包后，服务器忙于读写业务，没有及时给予答复。
需检查服务端释放资源的代码以及处理请求的线程配置。
请简述UDP和TCP的区别
| - | UDP | TCP |
|---|---|---|
| 连接方式 | 无连接，不需建立连接即可传输数据 | 面向连接，需要三次握手建立连接后才可以传输数据 |
| 数据可靠性 | 不可靠，数据可能丢失 | 可靠，运用停止等待协议或连续ARQ协议确保数据完整送达 |
| 有序性 | 无序，直接传输报文 | 拆分字节流，利用序列号进行排序 |
| 速度 | 快 | 慢，因为要经历三次握手 |
| 量级 | 轻，头部仅8字节 | 重，头部20字节起步 |
| 适用场景 | 发送邮件等可靠性要求高的场景 | 视频通话等效率要求高的场景 |
请简述TCP的滑动窗口
TCP使用滑动窗口做可靠传输和流量控制。
- 可靠传输：TCP会将数据视作字节流，当滑动窗口范围内位于首部的字节发送并被确认后，窗口将会向后推动。当某段字节长时间未被确认，将触发选择重传，以确保数据的完整性。
- 流量控制：接受方会将自身可用的窗口大小实时通知给发送方，发送方根据接受方的处理能力来动态控制发送速率。若发送方收到窗口大小为0的通知后，长时间未收到新的窗口通知，将发送窗口探测报文。
请简述浏览器键入URL后发生的过程
- 首先进行DNS解析，沿着本地浏览器缓存、系统缓存、路由器缓存、IPS服务器缓存、根域名服务器缓存、顶级域名服务器缓存的顺序查找，直至解析出该域名对应的IP地址
- 然后与该IP地址建立TCP连接，客户端发送SYN包后进入同步已发送状态，服务端回复SYN+ACK包后进入同步已接收状态，客户端发送ACK包后完成三次握手
- 客户端发送HTTP请求
- 服务器处理请求并返回HTTP响应
- 浏览器解析响应并渲染页面
- 最后关闭TCP连接，客户端发送FIN包后进入完成等待态1，服务端答复ACK包后进入关闭等待态，客户端进入完成等待态2；服务端也发送一个FIN包并进入最终确认态，客户端答复ACK包后开启2MSL时长的定时器，最终完成四次挥手
简述HTTP状态码
五种大类：
| 类型 | 含义 |
|---|---|
| 1xx | 请求已接收，需继续执行操作 |
| 2xx | 请求已被成功处理 |
| 3xx | 请求重定向 |
| 4xx | 客户端错误 |
| 5xx | 服务端错误 |
常见状态码：
| 状态码 | 英文 | 含义 |
|---|---|---|
| 100 | Continue | 服务器告知客户端继续传输数据 |
| 200 | OK | 请求成功，正常返回信息 |
| 301 | Permanently Moved | 资源被永久转移，需重定向 |
| 302 | Temporarily Moved | 资源被临时转移，需重定向 |
| 400 | Bad Request | 请求有语法错误 |
| 401 | Unauthorized | 请求未经授权 |
| 403 | Forbidden | 服务器拒绝提供服务 |
| 404 | Not Found | 请求的资源不存在 |
| 500 | Internal Server Error | 服务器内部错误 |
| 503 | Server Unavailable | 服务器当前无法处理请求 |
简述GET和POST的区别
| - | GET | POST |
|---|---|---|
| HTTP报文层面 | 请求信息位于URL中，有长度和编码的限制 | 请求信息在报文体中，无长度和编码的限制 |
| 数据库层面 | 符合幂等性和安全性 | 不符合幂等性和安全性 |
| 其它层面 | 可以被缓存 | 无法被缓存 |
简述Cookie和Session的区别
| - | Cookie | Session |
|---|---|---|
| 存储位置 | 客户端浏览器 | 服务器 |
| 安全性 | 易被窃取，存在安全隐患 | 安全 |
| 性能 | 无性能问题 | 过多的会话会加重服务器负担 |
简述HTTP和HTTPS的区别
| - | HTTP | HTTPS |
|---|---|---|
| 传输方式 | 明文传输 | 密文传输 |
| 连接方式 | 80端口 | 443端口 |
| 数字证书 | 无需申请 | 需要在CA申请 |
| 安全性 | 无保护措施 | 对称加密+非对称加密+数字证书+SSL |
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
