【iOS】架构师之路~ 网络篇

互联网协议按照功能不同分为osi七层和tcp/ip五层或tcp/ip四层，如下图：

套接字是工作在传输层和应用层之间的一个接口，将复杂的tcp/udp协议隐藏在了socket接口后面

并没有用过，做以下了解：

WebSocket 是 HTML5 一种新的协议。它实现了浏览器与服务器全双工通信，能更好的节省服务器资源和带宽并达到实时通讯，它建立在 TCP 之上，同 HTTP 一样通过 TCP 来传输数据，但是它和 HTTP 最大不同是：WebSocket 是一种双向通信协议.

iOS WebSocket长链接

你怎么理解分层和协议？

A. 如何理解分层

分层的理由:

• 独立性 通过分层，每一层值接受下一层提供的特定服务，并且负责为上一层提供特定服务，上下层之间进行交互所遵循的约定叫“接口”，同一层之间的交互所遵循的约定叫做“协议”。每一层可以独立使用，及时系统中某些层次发生变化，也不会波及系统。
• 灵活性好 对于任何一层的改动，只要上下层接口不变，都不会造成系统的问题，有利于每一层功能的扩展和变动。
• 易于实现和维护 将大问题简化为小问题，大系统简化为小层次。比如将网络的通信过程划分为小一些、简单一些的部件,因此有助于各个部件的开发、设计和故障排除。
• 能促进标准化工作 通过分层，定义在模型的每一层实现什么功能,有利于鼓励产业的标准化，同时允许多个供应商进行开发。

分层的原则：

• 各个层之间有清晰的边界,便于理解;
• 每个层实现特定的功能;
• 层次的划分有利于国际标准协议的制定;
• 层的数目应该足够多，以避免各个层功能重复

B. 如何理解协议

协议 实际上是一种 通信双方共同遵守 的 规范 。比如我需要把 性别 和 年龄 传递给另外一台主机，那么我可以定义一个 "A 协议" ，协议规定数据的 前 4 个字节 表示 性别 ， 后四个字节 表示 年龄 。这样 对方主机 接收时就知道 前 4 个字节 是 性别 ，而不会错把它当成 年龄 来处理。

协议 的规范和共同遵守，有利于各个分层之间的交流和处理，也有利于促进 协议 的 标准化过程 。

路由器和交换机的工作原理大概是什么，他们分别用到什么协议，位于哪一层

交换机:

二层交换机:

二层交换机 是一种在 数据链路层 工作的 网络设备 ，一般要求支持 802.1q（就是划VLAN） 、 SNMP 、 限速 、 广播风暴控制 、 ACL 、 组播 这些常见的功能；它有多个端口，可以连接不同的设备。 交换机 根据每个帧中的 目标 MAC 地址 决定向哪个端口发送数据，此时它需要参考 “转发表” 转发表 并非手动设置，而是交换机自动学习得到的。当某个设备向交换机发送帧时，交换机将帧的源 MAC 地址 和 接口 对应起来，作为 一条记录 添加到 转发表 中。 下图描述了 交换机自学过程 的原理：

三层交换机

三层交换机 具有 路由器功能 ，工作在 网络层 ，在二层的基础上支持如 静态路由 、 RIP(矢量路由选择协议) 、 OSPF(链路状态路由选择协议) 、 BGP(边界网关协议) 、 ISIS(分级的链接状态路由协议) 等路由协议，有时候会要求支持 MPLS(多协议标签交换) 、 GRE(通用路由封装协议) 、 L2TP(工业标准的Internet隧道协议) 、 IPSec(Internet 协议安全性)等隧道协议 。三层交换机上能够对分组报文根据 IP地址 进行转发。

四到七层交换机

负责处理 OSI模型 中从 传输层 至 应用层 的数据。如果用 TCP/IP分层模型 来表述， 4-7层交换机 就是以 传输层 及其上面的 应用层 为基础，进行 分析数据 ，并对其进行特定的处理。

例如：对于 并发访问量 非常大的一个 企业级Web站点 ，使用一台服务器不足以满足前端的访问需要，这时通常会通过 多台服务器 来分担，这些服务器前端访问的入口地址通常只有一个（企业为了使用者的方便，只会向最终的用户开放一个统一的 访问URL ）。为了能通过 同一个URL 将前端访问分发到后台多个服务器上，可以在这些服务器的前端加一个 负载均衡器 。这种 负载均衡器 就是 4-7层交换机 的一种。

此外，实际通信当中，人们希望在网络比较拥堵的时候，优先处理像语音这类对及时性要求较高的通信请求，放缓处理像邮件或数据转发等稍有延迟也并无大碍的通信请求，这种处理被称为 宽带控制 ，也是 4-7层交换机 的重要功能，还有其他很多功能，例如 广域网加速器 ，特 殊应用访问加速 以及 防火墙 等。

路由器

路由器 工作在 网络层 ，完成通过 路由控制 将 分组数据 发送到 目标地址 的功能。支持如 静态路由 、 RIP(矢量路由选择协议) 、 OSPF(链路状态路由选择协议) 、 BGP(边界网关协议) 、 EGP(外部网关协议) 、 ISIS(分级的链接状态路由协议) 等路由协议。 路由器中保存着 路由控制表 ，它在 路由控制表 中查找 目标IP地址 对应的 下一个路由器地址 。下图描述了这一过程：

主机A 的地址是 10.1.1.30 ,要把数据发往地址为 10.1.2.10 的主机。在 主机A 的路由表中，保存了两个字段，由于目标地址 10.1.2.10 与 10.1.1.0/24 段不匹配，所以它被发往默认路由 10.1.1.1 也就是图中路由器1的左侧网卡的 IP地址 。 路由器1 继续在它自己的 路由控制表 中查找 目标地址10.1.2.10 ，它发现目标地址属于 10.1.2.0/24 这一段，因此将数据转发至下一个路由器 10.1.0.2 ，也就是 路由器2 的左侧网卡的地址。 路由器2 在自己的 路由控制表 中查找 目标地址10.1.2.10 ，根据表中记录将数据发往 10.1.2.1接口 ，也就是自己的 右侧网卡 的 IP地址 。 主机B 检查目标 IP地址 和自己相同，于是接收数据。

[网络面试问题]]( www.jianshu.com/p/5553ada4a… )

简介 TCP 和 UDP 区别，他们位于哪一层？

TCP 和 UDP 位于OSI 七层模型的第四层：传输层，区别如下：

1、连接性:
	 TCP 面向连接（如打电话要先拨号建立连接）;
	 UDP 是面向无连接的，即发送数据之前不需要建立连接
2、可靠性：
   TCP 提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达; 
	 UDP尽最大努力交付，即不保证可靠交付
3、传输内容：
	 TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;
	 UDP是面向报文的，UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
4、服务性质：
	 TCP连接只能是点到点的;
	 UDP支持一对一，一对多，多对一和多对多的交互通信
5、开销：
	 TCP首部开销20字节;
	 UDP的首部开销小，只有8个字节
6、信道
	 TCP的逻辑通信信道是全双工的可靠信道
	 UDP则是不可靠信道
复制代码

描述TCP 协议三次握手，四次释放的过程？

TCP 三次握手

• 第一次握手: 客户端 将 标志位SYN 置为 1 ，随机产生一个 序列值seq = x ，并将该数据包发送给 服务端 , 客户端 进入 SYN_SENT 状态，等待 服务端 确认。

• 第二次握手: 服务端·收到数据包后由 标志位 SYN=1 ，知道 客户端 请求建立连接， 服务端 将 标志位SYN 和 ACK 都置为 1 ， ack = x + 1 ，随机产生一个值 seq = y , 并将该数据包发送给 客户端 以确认连接请求， 服务端 进入 SYN_RCVD 状态。

• 第三次握手:

  客户端 收到确认后，检查 ack 是否为 x+1 ， ACK 是否为 1 ，如果正确将 标志位ACK 置为 1 ， ack = y + 1 , 并将该数据包发送给 服务端 , 服务端 检查 ack 是否为 y+1 ， ACK 是否为 1 ，如果都正确则连接建立成功， 客户端 和 服务端 进入 ESTABLISHED 状态，完成三次握手，随后 客户端 与 服务端 之间开始进行数据传输。

TCP 四次挥手

• 第一次挥手: 客户端 发出连接 释放报文 ，并且停止发送数据。将 释放数据报文首部 的 FIN 置为 1 ， 序列号seq 置为 u （等于前面已经传送过来的数据的 最后一个字节的序号加1 ），此时， 客户端 进入 FIN-WAIT-1（终止等待1） 状态。 TCP 规定， FIN 报文段即使不携带数据，也要消耗一个序号。
• 第二次挥手: 服务端 收到报文后，检查到首部的 FIN 为 1 ，知道 客户端 请求 释放连接 ， 服务端 发出 确认报文 ，并将报文首部的 ACK 置为 1 ， ack 置为 u + 1 ,并且带上自己的 序列号v ,此时服务端进入 CLOSE-WAIT(关闭等待状态) 。 客户端 收到 服务端 的 确认报文 后，检查 ACK 是否为 1 ， ack 是否为 u+1 ,如果都正确，客户端进入 FIN-WAIT-2(终止等待2) 状态。等待 服务端 发送连接 释放报文 。
• 第三次挥手: 服务端 将最后的数据发送完毕后，就向 客户端 发送连接 释放报文 ， FIN=1 , ack = u+1 , 序列号 为 seq = w (因为在半关闭状态，服务器很可能又发送了一些数据，假定此时的 序列号 为 seq=w )，此时 服务端 进入 LASK-ACK(最后确认) 状态，等待 客户端 确认。
• 第四次挥手: 客户端 接收 服务器 的报文后，检查 FIN 为 1 ，知道 服务端 请求 释放连接 ，发出 确认报文 ， ACK = 1 ， ack = w + 1 , seq = u + 1 , 此时 客户端 进入 TIME-WAIT(时间等待) 状态。注意此时TCP连接还没有释放，必须经过 2∗MSL （最长报文段寿命）的时间后，当客户端撤销相应的 TCB 后，才进入 CLOSED 状态。 服务端 只要收到 客户端 发出的 确认报文 ，检查 ACK 是否为 1 ， ack 是否为 w + 1 , 如果都正确，立即进入 CLOSE 状态。

TCP 三次握手过程？

结合TCP报文结构来看会比较清晰：

1、TCP服务器进程先创建传输控制块TCB，时刻准备接受客户进程的连接请求，此时服务器就进入了LISTEN（监听）状态；
2、TCP客户进程也是先创建传输控制块TCB，然后向服务器发出连接请求报文，这是报文首部中的同部位SYN=1，同时选择一个初始序列号 seq=x ，此时，TCP客户端进程进入了SYN-SENT（同步已发送状态）状态。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。
3、TCP服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文中应该 ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己初始化一个序列号 seq=y，此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据，但是同样要消耗一个序号。
4、TCP客户进程收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号。
5、当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就可以开始通信了。

参考：

[ 网络相关面试题 ]( www.javazhiyin.com/35813.html )

TCP 四次挥手过程？

1、客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2、服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3、客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4、服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5、客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6、服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

参考：

网络相关面试题

如何改进TCP

采取一块确认的机制

UDP是全双工吗？

所谓全双工，半双工，单工是指面向连接时才有的说法，如果不是面向连接的，没有一个确定的连接的话，怎么会出现半双工这种只准一个来或者一个去的说法呢？ UDP支持一对一，一对多，多对一和多对多的交互通信。如果一定要涉及到全双工的话，大概理解为不仅提供全双工，甚至提供全多工服务，只是UDP是不可靠的服务而已。

为什么要等待2MSL？

MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。

一、保证客户端发送的最后一个ACK报文能够到达服务器
		因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
二、防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。
  	客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

复制代码

TCP/IP，你必知必会的十个问题

网络相关面试题

为什么建立连接时是三次握手，两次行不行？如果第三次握手失败了怎么处理

A. 为什么是三次握手:

• 为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。
• 因为在网络请求中，我们应该时刻记住：“网络是不可靠的，数据包是可能丢失的”。
• 假设没有第三次确认， 客户端 向 服务端 发送了 SYN ，请求建立连接。由于延迟，服务端没有及时收到这个包。于是 客户端 重新发送一个 SYN 包。回忆一下介绍 TCP 首部 时提到的 序列号 ，这两个包的序列号显然是相同的。
• 假设服务端接收到了 第二个 SYN 包 ，建立了通信，一段时间后通信结束，连接被关闭。这时候最初被发送的 SYN 包 刚刚抵达 服务端 ， 服务端 又会发送一次 ACK 确认。由于两次握手就建立了连接，此时的 服务端 就会建立一个新的连接，然而 客户端 觉得自己并没有请求建立连接，所以就不会向 服务端 发送数据。从而导致 服务端 建立了一个空的连接，白白浪费资源。
• 在三次握手的情况下， 服务端 直到收到 客户端 的应答后才会建立连接。因此在上述情况下， 客户端 会接受到一个相同的 ACK 包 ，这时候它会抛弃这个数据包，不会和 服务端 进行第三次握手，因此避免了 服务端 建立 空的连接 。

B. 第三次握手失败了怎么处理

• 按照 TCP 协议 处理丢包的一般方法， 服务端 会重新向 客户端 发送 数据包 ，直至收到 ACK 确认 为止。但实际上这种做法有可能遭到 SYN 泛洪攻击 。所谓的 泛洪攻击 ，是指 发送方 伪造 多个 IP 地址 ，模拟 三次握手 的过程。当 服务器 返回 ACK 后，攻击方故意不确认，从而使得服务器不断重发 ACK 。由于 服务器 长时间处于 半连接状态 ，最后消耗过多的 CPU 和 内存资源 导致死机。
• 正确处理方法是 服务端 发送 RST 报文 ，进入 CLOSE 状态。这个 RST 数据包的 TCP 首部中，控制位中的 RST 位 被设置为 1 。这表示 连接信息 全部被初始化，原有的 TCP 通信不能继续进行。客户端如果还想重新建立 TCP 连接，就必须重新开始第一次握手。

关闭连接时，第四次握手失败怎么处理？

实际上，在 第三步 中， 客户端 收到 FIN 包 时，它会设置一个 计时器 ，等待相当长的一段时间。如果 客户端 返回的 ACK 丢失，那么 服务端 还会重发 FIN 并重置 计时器 。假设在 计时器 失效前 服务器 重发的 FIN 包 没有到达 客户端 ， 客户端 就会进入 CLOSE 状态，从而导致 服务端 永远无法收到 ACK 确认 ，也就无法 关闭连接 。

示意图如下：

为什么TCP握手是三次，挥手却是四次？（假设客户端主动，服务器端被动）

在 TCP 三次握手中，服务器端的 SYN 和 ACK 是放在一个 TCP报文段 中向 客户端 发送的，而在断开连接的过程中， 服务器端 向 客户端 发送的 ACK 和 FIN 是是分别在两个不同的 TCP 报文段中。这是因为在 服务器端 接收到 客户端 的 FIN 后， 服务器端 可能还有数据要传输，所以先发送 ACK ， 服务器端 把数据发完之后就可以发送 FIN 断开连接了。

为什需要三次握手？

《计算机网络》第四版中讲“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”

书中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。

假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”。主要目的防止server端一直等待，浪费资源。

参考：

从输入URL到页面展示，到底发生了什么

TCP如何保证可靠传输

○ 数据包校验 ○ 超时重传机制 ○ 应答机制 ○ 对失序数据包重排序 ○ TCP还能提供流量控制

TCP 协议是如何进行流量控制，拥塞控制的？

A. 如何进行流量控制:

• 流量控制 以动态调整发送 空间大小(滑动窗口) 的形式来反映 接收端 接收消息的能力，反馈给 发送端 以调整 发送速度 ，避免 发送速度 过快导致的 丢包 或者 过慢 降低整体性能。
• 这里采用 滑动窗口机制 ，一是不用每次发送完成都需要等待收到确认消息才能继续发送，二是参考 接收端 的接收能力，限制 发送数据段 大小，避免丢失现象。

B. 如何进行拥塞控制：

• 连接建立的初期，如果 窗口 比较大， 发送方 可能会突然发送大量数据，导致网络瘫痪。因此，在通信一开始时， TCP 会通过 慢启动 算法得出窗口的大小，对发送数据量进行控制。

流量控制 是由 发送方 和 接收方 共同控制的。刚刚我们介绍了 接收方 会把自己能够承受的 最大窗口长度 写在 TCP 首部 中，实际上在 发送方 这里，也存在 流量控制 ，它叫 拥塞窗口 。TCP 协议中的窗口是指 发送方窗口 和 接收方窗口 的较小值。 慢启动过程如下：

• 通信开始时， 发送方 的 拥塞窗口 大小为 1 。每收到一个 ACK 确认后， 拥塞窗口 翻倍。
• 由于 指数级增长 非常快，很快地，就会出现 确认包 超时。(超时是因为数据量大导致网络拥塞)
• 此时设置一个 “慢启动阈值” ，它的值是 当前拥塞窗口 大小的一半。
• 同时将 拥塞窗口大小 设置为 1 ，重新进入 慢启动过程 。
• 由于现在 “慢启动阈值” 已经存在，当 拥塞窗口 大小达到 阈值 时，不再翻倍，而是 线性增加 。
• 随着 窗口 大小不断增加，可能收到 三次重复确认 应答，进入 “快速重发” 阶段。 (快速重发: 当 发送端 连续收到 三个重复的ack 时，表示该 数据段 已经丢失，需要重发。当收到三个表示同一个数据段的 ack 时，不需要等待计时器超时，即重新发送数据段（当时这三个ack要在超时之前到达发送端），因为能够收到 接收端 的ack确认信息，所以数据段只是单纯的丢失，而不是因为 网络拥塞 导致，)
• 这时候， TCP 将 “慢启动阈值” 设置为 当前拥塞窗口大小 的一半，再将 拥塞窗口大小 设置成 阈值大小 （也有说加 3）。
• 拥塞窗口 又会 线性增加 ，直至下一次出现 三次重复确认 应答或 超时 。

以上过程可以用下图概括：

常见的 HTTP 状态码？

参考：

常见的HTTP状态码（HTTP Status Code）说明

从输入URL到页面展示，你想知道些什么？

从输入URL到页面展示，到底发生了什么？

过程为：

• URL 输入
• DNS 解析
• TCP 连接
• 发送 HTTP请求
• 服务器处理请求
• 服务器响应请求
• 浏览器解析，渲染页面
• 链接结束

参考

从输入URL到页面展示，到底发生了什么

从输入URL到页面展示，你想知道些什么？

另一个答案：

• 查询DNS，获取域名对应的IP地址 ○ 浏览器搜索自身的DNS缓存
○ 搜索操作系统的DNS缓存 ○ 读取本地的HOST文件 ○ 发起一个DNS的系统调用
• 宽带运营服务器查看本身缓存 • 运营商服务器发起一个迭代DNS解析请求 • 浏览器获得域名对应的IP地址后，发起HTTP三次握手 • TCP/IP连接建立起来后，浏览器就可以向服务器发送HTTP请求了 • 服务器接受到这个请求，根据路径参数，经过后端的一些处理生成HTML页面代码返回给浏览器 • 浏览器拿到完整的HTML页面代码开始解析和渲染，如果遇到引用的外部JS，CSS,图片等静态资源，它们同样也是一个个的HTTP请求，都需要经过上面的步骤 • 浏览器根据拿到的资源对页面进行渲染，最终把一个完整的页面呈现给用户

网络相关面试题

对 Cookie 的认识 ？

HTTP 协议对于发送的请求和响应不做持久化处理。这时候引入了 Cookie 技术用于状态管理。Cookie 对用与登录的状态管理，没有 Cookie 这个技术的话，因为 HTTP 不保存状态，每次打开新网页都必须再次登录。
Cookie 会根据响应报文中的 Set-Cookie 字段来通知客户端自动保存 Cookie。下次请求时会自动发送 Cookie，服务器会比对数据得到状态结果。

Session 和 Cookie 的作用和工作原理？

Cookie（复数形态：Cookies）：是指某些网站为了辨别用户身份、进行session跟踪而储存在用户本地终端上的数据（通常经过加密）。

作用：因为HTTP协议是无状态的，即服务器不知道用户上一次做了什么，这严重阻碍了交互式Web应用程序的实现。在典型的网上购物场景中，用户浏览了几个页面，买了一盒饼干和两饮料。最后结帐时，由于HTTP的无状态性，不通过额外的手段，服务器并不知道用户到底买了什么。为了做到这点，就需要使用到Cookie了。服务器可以设置或读取Cookies中包含信息，借此维护用户跟服务器会话中的状态。

Cookie的根本作用就是在客户端存储用户访问网站的一些信息。典型的应用有

1、记住密码，下次自动登录

2、购物车功能

3、记录用户浏览数据，进行商品（广告）推荐

工作原理：

1.创建 Cookie

​ 当用户第一次浏览某个使用Cookie的网站时，该网站的服务器就进行如下工作

​ 1.1 该用户生成一个唯一的识别码（Cookie id），创建一个Cookie对象

​ 1.2 默认情况下它是一个会话级别的cookie，存储在浏览器的内存中，用户退出浏览器之后被删除。如果网站希望浏览器将该Cookie存储在磁盘上，则需要设置最大时效（maxAge），并给出一个以秒为单位的时间（将最大时效设为0则是命令浏览器删除该Cookie）

​ 1.3 将Cookie放入到HTTP响应报头，将Cookie插入到一个 Set-Cookie HTTP请求报头中

​ 1.4 发送该HTTP响应报文

2.设置存储 Cookie

​ 浏览器收到该响应报文之后，根据报文头里的Set-Cookied特殊的指示，生成相应的Cookie，保存在客户端。该Cookie里面记录着用户当前的信息。

3.发送Cookie

​ 当用户再次访问该网站时，浏览器首先检查所有存储的Cookies，如果某个存在该网站的Cookie（即该Cookie所声明的作用范围大于等于将要请求的资源），则把该cookie附在请求资源的HTTP请求头上发送给服务器

4.读取Cookie

​ 服务器接收到用户的HTTP请求报文之后，从报文头获取到该用户的Cookie，从里面找到所需要的东西

Session:代表服务器与浏览器的一次会话过程，这个过程是连续的，也可以时断时续的。Session是一种服务器端的机制，Session 对象用来存储特定用户会话所需的信息

工作原理：创建session、使用session，具体看参考url

作用：Session的根本作用就是在服务端存储用户和服务器会话的一些信息

1、判断用户是否登录

2、购物车功能

参考：

Cookie和Session的作用和工作原理

谈对 5G技术的认识？

第一次有人把5G讲的这么简单明了

如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

网络相关面试题

Http 和 Https的区别？

1. 安全性：
	http是HTTP协议运行在TCP之上。所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。
	https是HTTP运行在SSL/TLS之上，SSL/TLS运行在TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。此外客户端可以验证服务器端的身份，如果配置了客户 端验证，服务器方也可以验证客户端的身份。

2. 证书
https协议需要到ca申请证书，一般免费证书很少，需要交费。

3. 传输协议
http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议

4. 端口
http和https使用的是完全不同的连接方式用的端口也不一样,前者是80,后者是443。

复制代码

HTTPS 原理?

HTTPS其实是有两部分组成：HTTP + SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。

HTTPS 是 HTTP 建立在 SSL/TLS 安全协议上的。

在 iOS 中，客户端本地会存放着 CA 证书，在HTTPS 请求时，会首先像服务器索要公钥，获得公钥后会使用本地 CA 证书验证公钥的正确性，然后通过正确的公钥加密信息发送给服务器，服务器会使用私钥解密信息。

HTTPS 相对于 HTTP 性能上差点，因为多了 SSL/TLS 的几次握手和加密解密的运算处理，但是加密解密的运算处理已经可以通过特有的硬件来加速处理。

1. 客户端发起HTTPS请求

这个没什么好说的，就是用户在浏览器里输入一个https网址，然后连接到server的443端口。

2. 服务端的配置

采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。这套证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。

3. 传送证书

这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

4. 客户端解析证书

这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值。然后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。

5. 传送加密信息

这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

6. 服务段解密信息

服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。

7. 传输加密后的信息

这部分信息是服务段用私钥加密后的信息，可以在客户端被还原

8. 客户端解密信息

客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。
复制代码

https工作原理

简单粗暴系列之HTTPS原理

经典面试题21 - HTTPS 和 SSL证书原理

HTTP 请求中的 get 和 post 的区别?

1. GET使用URL或Cookie传参，而POST将数据放在BODY中，这个是因为HTTP协议用法的约定。并非它们的本身区别。
2. GET方式提交的数据有长度限制，则POST的数据则可以非常大，这个是因为它们使用的操作系统和浏览器设置的不同引起的区别。也不是GET和POST本身的区别。
3. POST比GET安全，因为数据在地址栏上不可见，这个说法没毛病，但依然不是GET和POST本身的区别。
4. 最大的区别主要是GET请求是幂等性的，POST请求不是

HTTP｜GET 和 POST 区别？网上多数答案都是错的！

另一个答案：

网络面试题

Session 和 Cookie 的区别?

HTTP 是一种 无状态 的连接， 客户端 每次读取 web 页面 时， 服务器 都会认为这是一次 新的会话 。但有时候我们又需要 持久保持 某些信息，比如登录时的 用户名、密码 ，用户上一次连接时的信息等。这些信息就由 Cookie 和 Session 保存。 这两者的根本性区别在于， cookie 保存在 客户端 上，而 session 则保存在 服务器 中。由此我们还可以拓展出以下结论：

• cookie 相对来说不安全，浏览器可以分析本地的 cookie 进行 cookie 欺骗。
• session 可以设置超时时间，超过这个时间后就失效，以免长期占用 服务端 内存。
• 单个 cookie 的大小有限制 （4 Kb） ，每个站点的 cookie 数量一般也有限制 （20个） 。
• 客户端 每次都会把 cookie 发送到 服务端 ，因此 服务端 可以知道 cookie ，但是 客户端 不知道 session 。

当 服务器 接收到 cookie 后，会根据 cookie 中的 SessionID 来找到这个客户的 session 。如果没有，则会生成一个新的 SessionID 发送给客户端。

谈谈你对 HTTP 1.1，2.0 和 HTTPS 的理解?

一、HTTP

HTTP（超文本传输协议，HyperText Transfer Protocol) 是 应用层 的协议，目前在互联网中应用广泛。

它被设计用于 Web浏览器 和 Web服务器 之间的通信，但它也可以用于其他目的。 HTTP 遵循经典的 客户端-服务端模型 ，客户端打开一个连接以发出请求，然后等待它收到 服务器端 响应。 HTTP 是 无状态协议 ，意味着 服务器 不会在两个请求之间保留任何数据（状态）。

二、HTTP1.0 ——构建可扩展性

HTTP 1.0 规定 浏览器 与 服务器 只保持短暂的连接， 浏览器 的每次请求都需要与 服务器 建立一个 TCP连接 ， 服务器 完成请求处理后立即断开 TCP连接 ，服务器不跟踪每个客户也不记录过去的请求。

三、 HTTP1.1 ——标准化的协议

HTTP/1.0 的多种不同的实现运用起来有些混乱， HTTP1.1 是第一个标准化版本，重点关注的是 校正HTTP1.0 设计中的结构性缺陷：

• 连接可以重复使用，节省了多次打开它的时间，以显示嵌入到单个原始文档中的资源。
• 增加流水线操作，允许在第一个应答被完全发送之前发送第二个请求，以降低通信的延迟。
• 支持响应分块。
• 引入额外的缓存控制机制。
• 引入内容协商，包括语言，编码，或类型，并允许客户端和服务器约定以最适当的内容进行交换。
• 添加Host 头，能够使不同的域名配置在同一个IP地址的服务器。
• 安全性得到了提高

在 http1.1 中， client 和 server 都是默认对方支持长链接的， 如果不希望使用长链接，则需要在 header中 指明 connection:close ；

四、HTTP2.0——为了更优异的表现

HTTP/2.0 在 HTTP/1.1 有几处基本的不同:

• HTTP2 是 二进制协议 而不是 文本协议 。不再可读和无障碍的手动创建，改善的优化技术现在可被实施。
• 这是一个复用协议。并行的请求能在同一个链接中处理，移除了HTTP/1.x中顺序和阻塞的约束。
• 压缩了headers。因为headers在一系列请求中常常是相似的，其移除了重复和传输重复数据的成本。
• 其允许服务器在客户端缓存中填充数据，通过一个叫服务器推送的机制来提前请求。

五、HTTPS

我们知道 HTTP 协议直接使用了 TCP 协议进行数据传输。由于数据没有加密，都是直接 明文 传输，所以存在以下三个风险：

• 窃听风险：第三方节点可以获知通信内容。
• 篡改风险：第三方节点可以修改通信内容。
• 冒充风险：第三方节点可以冒充他人身份参与通信。

比如你在手机上打开应用内的网页时，有时会看到网页底部弹出了广告，这实际上就说明你的 HTTP 内容被窃听、并篡改了。 HTTPS 协议旨在解决以上 三个风险 ，因此它可以：

• 保证所有信息加密传输，无法被第三方窃取。
• 为信息添加校验机制，如果被第三方恶意破坏，可以检测出来。
• 配备身份证书，防止第三方伪装参与通信。

HTTPS 的结构如图所示：

可见它仅仅是在 HTTP 和 TCP 之间新增了一个 TLS/SSL 加密层，这也印证了一句名言：“一切计算机问题都可以通过添加中间层解决”。 使用 HTTPS 时， 服务端 会将自己的证书发送给 客户端 ，其中包含了 服务端 的公钥。基于 非对称加密 的传输过程如下：

• 客户端使用公钥将信息加密，密文发送给服务端
• 服务端用自己的私钥解密，再将返回数据用私钥加密发回客户端
• 客户端用公钥解密

这里的 证书 是 服务器 证明自己身份的工具，它由权威的 证书颁发机构（CA） 发给申请者。如果证书是虚假的，或者是自己给自己颁发的证书，服务器就会不认可这个证书并发出警告：

总结一下 HTTPS 协议 是如何避免前文所说的三大风险的：

• 先用 非对称加密 传输密码，然后用这个密码对称 加密数据 ，使得第三方无法获得通信内容
• 发送方 将数据的 哈希结果 写到数据中， 接收方 解密后对比数据的 哈希结果 ，如果不一致则说明被修改。由于传输数据加密，第三方无法修改哈希结果。
• 由 权威机构颁发 证书，再加上 证书校验 机制，避免 第三方伪装 参与通信.

网络层面试题