一、解析 URL

首先，用户输入 URL 后浏览器根据输入的信息判断是进行 “搜索” 还是进行 “跳转网址”。如果是搜索内容，则将搜索内容加上默认的搜索引擎组合成新的 URL。如果用户输入的 URL 是合法网址，则直接跳转至输入的 URL 网址。

二、DNS 域名解析

浏览器通过 DNS 域名解析服务将输入的域名 解析为对应服务的 IP 地址，这样才能访问到域名指定的服务器。DNS 域名解析的过程如下：

1. 本地 DNS 服务器查询

客户端会依次在 浏览器缓存、本地 hosts 文件、本地 DNS 服务器缓存、本地 DNS 服务器 去查询域名，如果在任意一步查询到域名，直接返回域名对应的 IP 地址。

2. 根域名服务器、顶级域名服务器、权威域名服务器

如果在本地 DNS 服务器查询不到。那么本地 DNS 服务器则向上级域名服务器进行查询。查询过程为：

HTTPS 优化

HTTPS 连接大致上可以划分为两个部分，第一个是建立连接时的非对称加密握手，第二个是握手后的对称加密报文传输。由于目前流行的 AES、ChaCha20 性能都很好，还有硬件优化，报文传输的性能损耗可以说是非常地小，小到几乎可以忽略不计了。

所以，通常所说的“HTTPS 连接慢”指的就是刚开始建立连接的那段时间。这个步骤最长可以花费两个消息往返。而且在握手消息的网络耗时之外，还会有其他的一些“隐形”消耗，比如：

• 产生用于密钥交换的临时公私钥对（ECDHE）；
• 验证证书时访问 CA 获取 CRL 或者 OCSP；

一、HTTP 的不足

• 通信使用明文传输，内容可能会被窃听
• 不验证通信方的身份，有可能遭到伪装。服务端和客户端都有可能伪装。
• 无法证明报文的完整性，所以有可能已经遭到篡改。像这样，请求或响应在传输途中遭到攻击者拦截并篡改内容，称为“中间人攻击”

应用层主要提供应用进程间的网络通信服务，完成用户请求的各种服务。

一、HTTP 协议

http协议即超文本传输协议，基于TCP协议，用于从Web服务器传输超文本到本地浏览器的传送协议。http协议是无状态协议，自身不对请求和响应直接的通信状态进行保存，但有些场景下我们需要保存用户的登陆信息，所以引入了cookie 和 session 来管理状态。

1. cookie 和 session 的区别：

（1）保存位置与安全性：cookie保存在客户端，session保存在服务端，所以在安全性上面，cookie存在安全隐患，可以通过拦截或本地文件找到cookie后进行攻击，而session相对更加安全。因此，可以将登陆信息等重要信息存放为session中；其他信息如果需要保留，可以放在cookie中。
（2）存储容量：单个cookie最大只允许4KB，一个站点最多保存20个Cookie；session没有大小限制，个数只跟服务器的内存大小有关。
（3）有效期与实现机制：cookie可长期有效存在；session依赖于cookie，过期时间默认为-1，只需关闭窗口该 session 就会失效。每个客户端对应一个session ，客户端之间的 session 相互独立；

• cookie：cookie是一小段的文本信息，当客户端请求服务器时，如果服务器需要记录该用户状态，就在响应头中向客户端浏览器颁发一个Cookie，而客户端浏览器会把cookie保存起来。当再次请求该网站时，浏览器把请求的网站连同该cookie一起提交给服务器，服务器会检查该cookie，以此来辨认用户状态。

计算机网络模型：

TCP/IP 与 OSI 都是为了使网络中的两台计算机能够互相连接并实现通信与回应，但他们最大的不同在于，OSI 是一个理论上的网络通信模型，而 TCP/IP 则是实际上的网络通信标准。

一、OSI七层模型：

1. 物理层：实现计算机节点之间比特流的透明传输，规定传输媒体接口的标准，屏蔽掉具体传输介质和物理设备的差异，使数据链路层不必关心网络的具体传输介质，按照物理层规定的标准传输数据就行

2. 数据链路层：通过差错控制、流量控制等方法，使有差错的物理线路变为无差错的数据链路。

一、无数据传输的场景

1. 客户端主机崩溃

客户端主机崩溃了，服务端是无法感知到的。如果服务端没有开启 TCP 的保活机制，又没有进行数据交互，那么服务端的 TCP 连接将会一直处于 ESTABLISHED 连接状态，直到服务端重启进程。

所以，在没有 TCP 保活机制且双方不传输数据的情况下，一方的 TCP 连接处于 ESTABLISHED 状态，并不代表另一方的连接还一定正常。

2. 客户端进程崩溃

TCP 连接信息是由内核维护的，所以当服务端的进程崩溃后，内核需要回收该进程的所有 TCP 连接资源，于是内核会发送第一次挥手 FIN 报文，后续的挥手过程也都是在内核完成，并不需要进程的参与。所以即使服务端的进程退出了，还是能和客户端完成 TCP 四次挥手的过程。

我曾经做过实验，使用 kill -9 来模拟进程崩溃的情况，发现在 kill 掉进程后，服务端会发送 FIN 报文，与客户端进行四次挥手。

所以，即使没有开启 TCP 保活机制，且双方也没有数据交互的情况下，如果其中一方的进程发生了崩溃，这个过程操作系统是可以感知到的，操作系统会发送 FIN 报文给对方，然后与对方进行 TCP 四次挥手。

在网络上，TCP 针对数据包丢失的情况，会用重传机制解决。常见的重传机制包括：超时重传、快速重传、SACK、D-SACK。

1. 超时重传

在发送数据时，设定一个定时器，当超过指定的时间后，没有收到对方的 ACK 确认应答报文，就会重发该数据。这就是超时重传。一般有两种情况：数据包丢失、确认应答丢失。

那么超时时间应该设置为多少呢？

• RTT（Round-Trip Time）往返时延。指的是数据发送时刻到接收到确认的时刻的差值。也就是报文的往返时间。

本文我们结合 TCP 的三次握手、四次挥手，来谈一谈 socket 相关的系统调用。

一、socket 系统调用

socket() ：负责产生一个套接字的描述符

bind()：将创建好的 socket 与地址（IP 以及端口）绑定

listen()：为接收用户请求做好就绪准备，比如初始化好半连接队列、全连接队列。listen 的第二个参数 backlog 与全连接队列的最大长度有关。

accept()：一般情况下，如果没有请求到来，那么服务器会阻塞在 accept 函数上。当有请求时，也就是全连接队列中有已经就绪的连接时，他会返回一个新的描述符。这个新的描述符代表可以与客户端通信的 TCP 连接。

传输层主要提供不同主机上进程间 逻辑通信 + 可靠传输 或者 不可靠传输的功能。

一、TCP 和 UDP：

1. 传输控制协议TCP 和 用户数据报协议UDP的区别？
   （1）TCP是面向字节流的，基本传输单位是TCP报文段；UDP是面向报文的，基本传输单位是是用户数据报；

   • 面向字节流：应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序看成是一连串的无结构的字节流。TCP有一个缓冲，当应用程序传送的数据块太长，TCP就可以把它划分短一些再传送。

一、问题

在使用 TCP 网络编程时，比如 send/write 调用成功后，调用 close 关闭 socket。这种场景中有可能出现，发送的数据，传输到对端不完整。

二、原因

send() 成功返回只意味着内核接收了数据，并准备在某个特定的时间发送他们。内核在接收到数据后，还要把数据包发送到网卡等等一系列过程之后，最终数据才能到达对端主机。对端主机的内核收到数据后，然后拥有对应 socket 的进程从中读取数据。此时，数据才算是真正的完成了传输。

当调用 close() 关闭 socket 的时候，整个 TCP 连接也随之关闭。但此时可能还有数据在内核的发送缓冲区中，或者已经发送但未被确认。发送方如果 send() 后立即进行 close()，就可能出现数据其实还未发送的情况。

设置 socket 选项 SO_LINGER 会尝试将残留在内核发送缓冲区的数据发送给对方，这种看似解决了问题，但有时依然会出现数据发送不全的问题。

原因在于，发送方执行 close() 的时候，如果他的接收缓冲区中仍有数据没有读取，或者调用 close() 后有新的数据到达，这时他会发送一个 RST 报文告知对方数据丢失，没有正常使用 FIN 四次挥手断开连接，因此设置 SO_LINGER 没有效果。