本文内容基于JavaGuide.

常见的计算机网络体系结构

通常大家都会提到的五层、七层协议的体系结构，这里使用这种的五层协议。

1⃣️ 应用层 Application Layer

任务：通过进程间的交互来完成特定的网络应用。（进程：主机中正在运行的程序）
应用层协议有DNS， HTTP等。
应用层交互的数据单元称为报文。

2⃣️ 运输层 Transport Layer

任务：负责向两台主机进程之间的通信提供通用的数据传输服务。
主要协议
1. TCP：面向连接的，可靠的数据传输服务
2. UDP：无连接的，尽最大努力的数据传输服务

3⃣️ 网络层

任务：选择合适的网间路由和交换节点，确保数据的及时传送
协议：IP协议（Internet Protocol）

TCP相关

TCP三次握手和四次挥手

撇开handshake的流程而言，重要的是应该知道为什么要进行这样的流程。下面先记录它的目的。

为什么要三次握手？

三次握手的目的是建立可靠的通讯通道。也就是数据的发送和接收。换言之，三次握手的目的就是双方确认自己与对方的发送和接收是正常的。

三次握手流程

下面用表格代图表示三次握手的流程及他们都确认了什么：

发送端状态	数据传输	接收端状态	确认内容
SYN-SENT
	>>>发送带有SYN标志的数据包>>>	SYN-RECEIVED	接收端确认：对方发送正常，自己接收正常

	<<<发送带有SYN-ACK标志的数据包<<<
ESTABLISHED			发送端确认：自己发送、接收正常，对方发送、接收正常
	>>>发送带有ACK标志的数据包>>>	ESTABLISHED	两端均确认：自己发送、接收正常，对方发送、接收正常

为什么要4次挥手？

TCP是一个全双工的，最后两个终端都需要分别进行关闭。（全双工：发送的同时也能接收，即双向的）任何一方都可以在数据传送结束后发出释放连接的通知，待双方确认后进入半关闭状态。当另一方也没有数据再发送的时候，再放出释放连接的通知，对方确认后，就完全关闭连接。

四次挥手流程

主动关闭方状态	数据传输	被动关闭方状态	确认内容
FIN-WAIT 1
	>>>发送FIN，带有一个序列号>>>	CLOSE_WAIT	主动关闭方用来关闭客户端到服务器的数据传送
FIN-WAIT 2	<<<发送ACK，确认序号为收到的+1<<<	CLOSE_WAIT
TIME_WAIT	<<<发送FIN<<<	LAST_ACK	服务器关闭与客户端的连接
	>>>发送带有ACK报文确认，并将确认序号设置为收到的序列号+1>>>	CLOSED	两端均确认：自己发送、接收正常，对方发送、接收正常
CLOSED

TCP和UDP协议的区别

我认为重要的还是知道他们彼此到底是什么。在文章开始提到这两个协议时就有简短的介绍。这个介绍是基于他们的主要特征的。而提到的特征也往往是对方不具有的。

TCP：面向连接的，可靠的数据传输服务

UDP：无连接的，尽最大努力的数据传输服务

除了面向连接与否、可靠与否，这些导致了什么更是他们的重要区别。

TCP面向连接，所以传输数据之前必须通过三次握手建立连接，数据传输结束之后要四次挥手释放连接。这体现了TCP是一种可靠的数据传输服务。并且三次握手、四次挥手中，我们都提到报文是带有各种标志的，如SYN， ACK。这些标志也导致了数据单元的首部增大很多，所以需要很多资源分配。除此之外，TCP为什么还是可靠的呢？在下一个部分再详细介绍。

反之UDP不需要建立连接，所以他没有TCP可靠。但是由于他不需要建立连接，所以它的工作量和需要的资源都比较少，传输效率比较起来更高。

TCP如何保证可靠传输

这部分问题我上次面试中又被问到，回答的很差。尽管我记下了一些专业术语，却对实际应用场景非常陌生。希望大家能吃透它的原理，以此更加了解他的应用。

1. 校验和 Check Sum

校验和是对传输数据内容的check sum。发送方和接收端都会对数据进行计算然后对比。我看到的计算方式是将传输数据内容都当作一个16位的整数，然后对分段的16位证书都加起来，进位不遗弃，补在最后，然后取反。计算过程请大家再做搜索研究。

如果不一致，数据传输一定有误。反之不一定。

2. 确认应答和序列号

发送端发出的每条报文都有序列号（SYN），而接收端收到后进行确认应答时带有确认序列号（ACK），为接收到报文的序列号加一。

序列号还帮助了重构有序数据并且去除重复数据。也体现了TCP的传输可靠性。

3. 超时重传

发送方发送数据后会等待回复的带有ACK标志的报文一段时间。如果过了这段时间还没有收到，则会重新发送刚刚的数据。

4. 连接管理

即三次握手和四次挥手的过程。保证可靠的连接，是保证可靠性的前提。

5. 流量控制

TCP连接的每一方都有固定大小的缓冲空间。接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方数据时，提示发送方降低发送的速率，防止丢包。TCP根据接收端对数据的处理能力，决定发送端的发送速度，这个机制就是流量控制。TCP使用的流量控制协议时可变的滑动窗口。

如果接收到的窗口大小的值为0，那么发送方将停止发送数据。并定期向接收端发送窗口探测数据端。如果窗口大小恢复后，继续开始发送。

6. 拥塞控制

当有大量数据发送时，可能网络会很拥堵。如果依然发送大量数据的话，拥堵加剧会长生大量丢包。然后大量的超时重传就会严重影响运输。

//TODO：详细介绍

慢启动
拥塞避免
快重传和快恢复

从URL输入到页面展现发生了什么？

通过网址，解析域名获取IP地址
三次握手建立TCP连接
发送HTTP请求
服务器处理请求并返回HTTP报文
浏览器解析渲染页面
四次挥手结束连接

HTTP相关

HTTP的长连接和短连接

这也是HTTP/1.0和HTTP/1.1的区别。

HTTP/1.0默认使用短连接。也就是客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。

而HTTP/1.1开始默认使用长连接。在使用长连接的情况下，客户端和服务器只见用于传输HTTP数据的TCP连接不会关闭。这个连接并非永久保持，而是有一个保持时间，可以在不同的服务器软件中设定。实现长连接需要客户端和服务器都支持。

实质上，HTTP的长连接和短连接是TCP的长连接和短连接。

HTTP是不保存状态的协议，如何保存用户状态？

HTTP协议是一种不保存状态，即Stateless。换言之，HTTP协议自身不对请求和相应之前的通信状态进行保存。那么用户状态怎么保存呢？举个例子说明用户状态。当商品被加到购物车时，系统如何知道是哪个用户在操作呢？

Session就是为了解决这个问题的。Session通过服务器记录用户的状态。服务器给特定的用户创建特定的Session之后表示这个用户并进行跟踪。一般Session也有时间限制，过了时间限制之后，session会被销毁。

那么服务器如何保存Session呢？最常用的是内存和数据库。

接着服务器如何跟踪session呢？大部分情况，是在cookie中附加一个session id的方式来跟踪。而cookie是保存在客户端的。

cookie被禁用该怎么办呢？ JavaGuide中提到最常用的是在url后直接附上session id。我认为不太安全。详细请再做研究。

计算机网络基础