常见的计算机网络体系结构
OSI体系结构
法律上的国际标准：
由下向上：物理层->数据链路层->网络层->运输层->会话层->表示层->应用层
TCP/IP结构
实际上经常使用的标准：
由下向上：网络接口层->网际层->运输层->应用层
原理体系结构
由下向上：物理层->数据链路层->网络层->运输层->应用层
应用层
应用层常见协议：
- HTTP 超文本传输协议
- FTP 文件传输协议
- SMTP 简单邮件传输协议
- POP3/IMAP 邮件传输协议
HTTP协议
HTTP协议，全称超文本传输协议Hypertext Transfer Protocol。HTTP协议定义了浏览器（万维网客户进程）怎样向万维网服务器请求万维网文档，以及服务器怎样把文档传送给浏览器。
HTTP 是一个无状态（stateless）协议，也就是说服务器不维护任何有关客户端过去所发请求的消息。
HTTP协议通信过程
HTTP是应用层协议，它以TCP（传输层）作为底层协议，默认端口为80。 通信过程主要如下：
- 浏览器对URL进行解析；
- 通过DNS解析出IP，建立TCP连接；
- 客户端浏览器向服务器发出HTTP请求；
- Web服务器响应，并向浏览器发送数据；
- 关闭TCP连接
HTTP协议优点
- 简单、灵活、跨平台支持性好。
- HTTP是无状态的，可以轻松实现集群化，扩展性能。
- HTTP采用明文传输，数据完全肉眼可见，能够方便地研究和分析，但同时也容易被窃听。
HTTP协议缺点
- 通讯使用明文，未加密，并且TCP/IP协议是可能会被窃听的网络，所以通讯内容可能会被窃听
- 没有验证通讯方的身份，因此可能会遭遇伪装
- 没有办法验证报文的完整性，所以可能会被篡改
HTTPS协议
HTTPS HyperText Transfer Protocol Secure，是以安全为目标的 HTTP 通道。HTTPS经由HTTP进行通信，但利用SSL/TLS来加密数据包。HTTPS开发的主要目的，是提供对网站服务器的身份认证，保护交换资料的隐私与完整性。
HTTPS的默认端口号为443。
HTTPS协议优点
- 使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器。
- 使用HTTPS协议可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
- 尽管HTTPS不是绝对安全，但它大幅增加了中间人攻击的成本。
HTTPS协议缺点
- HTTPS协议握手阶段比较费时，会使页面的加载时间延长。
- HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗。
- HTTPS协议的加密范围也比较有限，而且SSL证书的信用链体系并不安全。
HTTP与HTTPS的区别
- HTTP 明文传输，数据都是未加密的，安全性较差，HTTPS（SSL+HTTP） 数据传输过程是加密的，安全性较好。
- HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS除了 TCP 的三个包，还要加上 ssl 握手需要的 9 个包，所以一共是 12 个包。
- http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。
- HTTPS 其实就是建构在 SSL/TLS 之上的 HTTP 协议，所以，要比较 HTTPS 比 HTTP 要更耗费服务器资源。
- 使用 HTTPS 协议需要到CA申请证书，一般免费证书较少，因而需要一定费用。
DNS 域名系统
域名系统DNS是因特网使用的命名系统，用来把便于人们记忆的具有特定含义的主机名转换为便于机器处理的IP地址。
因特网采用层次树状结构的域名结构。
域名解析过程使用的两种域名查询方法：
- 递归查询
- 迭代查询
为了提高DNS的查询效率并减轻根域名服务器的负荷和减少因特网上DNS查询报文数量，再域名服务器和主机中广泛地使用了高速缓存。
DNS报文使用运输层的UDP协议进行封装，端口号为53。
运输层
TCP
三次握手
- 客户端–发送带有
SYN标志的数据包–一次握手–服务端 - 服务端–发送带有
SYN/ACK标志的数据包–二次握手–客户端 - 客户端–发送带有带有
ACK标志的数据包–三次握手–服务端
为什么要三次握手
三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。
- 第一次握手：
- Client 什么都不能确认；
- Server 确认了对方发送正常，自己接收正常
- 第二次握手：
- Client 确认了：自己发送、接收正常，对方发送、接收正常；
- Server 确认了：对方发送正常，自己接收正常
- 第三次握手：
- Client 确认了：自己发送、接收正常，对方发送、接收正常；
- Server 确认了：自己发送、接收正常，对方发送、接收正常
四次挥手
- 客户端-发送一个
FIN，用来关闭客户端到服务器的数据传送 - 服务器-收到这个
FIN，它发回一个ACK，确认序号为收到的序号加 1 。和SYN一样，一个FIN将占用一个序号 - 服务器-关闭与客户端的连接，发送一个
FIN给客户端 - 客户端-发回
ACK报文确认，并将确认序号设置为收到序号加 1
为什么要四次挥手
任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了 TCP 连接。
可靠传输
ARQ协议
自动重传请求ARQAutomatic Repeat-reQuest是 OSI 模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。ARQ 包括停止等待协议和连续协议。
停止等待ARQ协议
停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认（回复 ACK）。如果过了一段时间（超时时间后），还是没有收到 ACK 确认，说明没有发送成功，需要重新发送，直到收到确认后再发下一个分组。
在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认。
- 优点：简单便于实现
- 缺点：信道利用率低，等待时间长
连续ARQ协议
连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累积确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。
- 优点： 信道利用率高，容易实现，即使确认丢失，也不必重传。
- 缺点： 不能向发送方反映出接收方已经正确收到的所有分组的信息。
流量控制
流量控制是为了控制发送方发送速率，保证接收方来得及接收。TCP利用滑动窗口实现流量控制。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。
拥塞控制
UDP
TCP协议和UDP协议区别
- TCP是面向连接的服务，而UDP再传输数据之前不需要建立连接；
- TCP提供可靠的传输服务，而UDP提供不可靠的传输服务；
- TCP在服务时使用流量控制和拥塞控制，而UDP不使用；
- TCP仅支持一对一通信，而UDP支持一对一、一对多和多对多交互通信；
- TCP首部开销最小20字节（，最大60字节），而UDP首部开销下，仅8字节。
其他常见面试题目
在浏览器地址栏输入URL地址到显示主页的过程
- 解析输入：浏览器根据用户输入的URL地址进行解析。
- 输入的是非
URL结构的字符串，则会用浏览器默认的搜索引擎搜索该字符串 - 输入的是
URL结构字符串，则会构建完整的URL结构，浏览器进程会将完整的URL通过进程间通信发送给网络进程
- 输入的是非
- DNS解析：将域名通过DNS解析为IP地址。
- TCP连接：客户端向服务器发起请求建立TCP连接。
- 发送HTTP请求：客户端浏览器向服务器发送HTTP请求。
- 服务器接收到HTTP请求做出响应，向客户端返回HTTP报文。
- 浏览器解析渲染页面：
- 开始渲染：
- 更新地址栏的安全状态
- 更新地址栏的
URL - 前进后退此时
enable，显示正在加载状态 - 更新网页
- 渲染过程：
- 解析
HTML生成DOM树 - 解析
CSS生成CSSOM - 加载或执行
JavaScript - 生成渲染树（
Render Tree） - 布局
- 分层
- 生成绘制列表
- 光栅化
- 显示
- 解析
- 开始渲染：
- 连接断开
Cookie 和 Session
Cookie 和 Session 都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样。
Cookie 一般用来保存用户信息 比如 ① 我们在 Cookie 中保存已经登录过的用户信息，下次访问网站的时候页面可以自动帮你把登录的一些基本信息给填了；② 一般的网站都会有保持登录，也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候我们可以存放了一个 Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑，重新登录一般要将 Token 重写)；③ 登录一次网站后访问网站其他页面不需要重新登录。
Session 的主要作用就是通过服务端记录用户的状态。 典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。
Cookie数据保存在客户端(浏览器端)，Session 数据保存在服务器端。
Cookie 存储在客户端中，而 Session 存储在服务器上，相对来说 Session 安全性更高。如果要在 Cookie 中存储一些敏感信息，不要直接写入 Cookie 中，最好能将 Cookie 信息加密，然后使用到的时候再去服务器端解密。
两者优缺点：
- 基于Session的会话保持优点是安全性较高，因为状态信息保存在服务器端。缺点是不便于服务器的水平扩展。大型网站的后台一般都不止一台服务器，可能几台甚至上百台，浏览器发送的HTTP请求一般要先通过负载均衡器才能到达具体的后台服务器，这就会导致每次HTTP请求可能落到不同的服务器上，比如说第一次HTTP请求落到server1上，第二次HTTP请求落到server2上。而Session默认是存储在服务器本机内存的，当多次请求落到不同的服务器上时，上述方案就不能实现会话保持了（常用解决方案是中间件，例如Redis，将Session的信信息存储在Redis中，这样每个server就都可以访问到）。
- 基于Cookie的会话保持的优点是服务器不用保存状态信息，减轻服务端存储压力，也便于服务端做水平扩展。缺点是不够安全，因为状态信息是存储在客户端的，这意味着不能在会话中保存机密数据，另一个缺点是每次HTTP请求都需要发送额外的Cookie到服务端，会消耗更多带宽。
HTTP协议是无状态的，如何保存用户状态
- 基于Session实现的会话保持
在会话开始时（客户端第一次像服务器发送http请求），服务器将会话状态保存起来（本机内存或数据库中），然后分配一个会话标识（SessionId）给客户端，这个会话标识一般保存在客户端Cookie中，以后每次浏览器发送http请求都会带上Cookie中的SessionId到服务器，服务器拿到会话标识就可以把之前存储在服务器端的状态信息与会话联系起来，实现会话保持（如果遇到浏览器禁用Cookie的情况，则可以通过url重写的方式将会话标识放在url的参数里，也可实现会话保持） - 基于Cookie实现的会话保持
基于Cookie实现会话保持与上述基于Session实现会话保持的最主要区别是前者完全将会话状态信息存储在浏览器Cookie中，这样一来每次浏览器发送HTTP请求的时候都会带上状态信息，因此也就可以实现状态保持。
URI 和 URL
- URI(Uniform Resource Identifier) 是统一资源标志符，可以唯一标识一个资源。
- URL(Uniform Resource Locator) 是统一资源定位符，可以提供该资源的路径。它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源。
URI 的作用像身份证号一样，URL 的作用更像家庭住址一样。URL 是一种具体的 URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。
HTTP状态码
| 100 | Continue | 继续。客户端应继续其请求 |
|---|---|---|
| 101 | Switching Protocols | 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议 |
| 200 | OK | 请求成功。一般用于GET与POST请求 |
| 201 | Created | 已创建。成功请求并创建了新的资源 |
| 202 | Accepted | 已接受。已经接受请求，但未处理完成 |
| 203 | Non-Authoritative Information | 非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本 |
| 204 | No Content | 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档 |
| 205 | Reset Content | 重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域 |
| 206 | Partial Content | 部分内容。服务器成功处理了部分GET请求 |
| 300 | Multiple Choices | 多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择 |
| 301 | Moved Permanently | 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替 |
| 302 | Found | 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI |
| 303 | See Other | 查看其它地址。与301类似。使用GET和POST请求查看 |
| 304 | Not Modified | 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源 |
| 305 | Use Proxy | 使用代理。所请求的资源必须通过代理访问 |
| 306 | Unused | 已经被废弃的HTTP状态码 |
| 307 | Temporary Redirect | 临时重定向。与302类似。使用GET请求重定向 |
| 400 | Bad Request | 客户端请求的语法错误，服务器无法理解 |
| 401 | Unauthorized | 请求要求用户的身份认证 |
| 402 | Payment Required | 保留，将来使用 |
| 403 | Forbidden | 服务器理解请求客户端的请求，但是拒绝执行此请求 |
| 404 | Not Found | 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面 |
| 405 | Method Not Allowed | 客户端请求中的方法被禁止 |
| 406 | Not Acceptable | 服务器无法根据客户端请求的内容特性完成请求 |
| 407 | Proxy Authentication Required | 请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权 |
| 408 | Request Time-out | 服务器等待客户端发送的请求时间过长，超时 |
| 409 | Conflict | 服务器完成客户端的 PUT 请求时可能返回此代码，服务器处理请求时发生了冲突 |
| 410 | Gone | 客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置 |
| 411 | Length Required | 服务器无法处理客户端发送的不带Content-Length的请求信息 |
| 412 | Precondition Failed | 客户端请求信息的先决条件错误 |
| 413 | Request Entity Too Large | 由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息 |
| 414 | Request-URI Too Large | 请求的URI过长（URI通常为网址），服务器无法处理 |
| 415 | Unsupported Media Type | 服务器无法处理请求附带的媒体格式 |
| 416 | Requested range not satisfiable | 客户端请求的范围无效 |
| 417 | Expectation Failed | 服务器无法满足Expect的请求头信息 |
| 500 | Internal Server Error | 服务器内部错误，无法完成请求 |
| 501 | Not Implemented | 服务器不支持请求的功能，无法完成请求 |
| 502 | Bad Gateway | 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应 |
| 503 | Service Unavailable | 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中 |
| 504 | Gateway Time-out | 充当网关或代理的服务器，未及时从远端服务器获取请求 |
| 505 | HTTP Version not supported | 服务器不支持请求的HTTP协议的版本，无法完成处理 |
