传输层 ：为进程提供通用数据传输服务。由于应用层协议很多，定义通用的传输层协议就可以支持不断增多的应用层协议。运输层包括两种协议：传输控制协议 TCP，提供面向连接、可靠的数据传输服务，数据单位为报文段；用户数据报协议 UDP，提供无连接、尽最大努力的数据传输服务，数据单位为用户数据报。TCP 主要提供完整性服务，UDP 主要提供及时性服务。

TCP transfer control protocol 传输控制协议，提供可靠的数据连接，

UDP user datagram protocol 用户数据报协议无连接的不保证数据传输的可靠性

网络层 ：为主机提供数据传输服务。而传输层协议是为主机中的进程提供数据传输服务。网络层把传输层传递下来的报文段或者用户数据报封装成分组。

数据链路层 ：网络层针对的还是主机之间的数据传输服务，而主机之间可以有很多链路，链路层协议就是为同一链路的主机提供数据传输服务。数据链路层把网络层传下来的分组封装成帧。

物理层 ：考虑的是怎样在传输媒体上传输数据比特流，而不是指具体的传输媒体。物理层的作用是尽可能屏蔽传输媒体和通信手段的差异，使数据链路层感觉不到这些差异

如何判断一个设备工作在什么层上面呢？

关键看它工作时利用哪一层的数据头部信息。

具体说: 比特流：物理层：网卡，网线，集线器，中继器，调制解调器

集线器是物理层设备,采用广播的形式来传输信息。

帧：数据链路层：网桥，交换机

交换机就是用来进行报文交换的机器。多为链路层设备(二层交换机，集线器发展而来)，能够进行地址学习，采用存储转发的形式来交换报文。

总之，交换机是一种基于MAC地址识别，能完成封装转发数据包功能的网络设备。交换机可以“学习”MAC地址，并把其存放在内部地址表中，通过在数据帧的始发者和目标接收者之间建立临时的交换路径，使数据帧直接由源地址到达目的地址。

分组：网络层：路由器

路由器的一个作用是连通不同的网络，另一个作用是选择信息传送的线路。选择通畅快捷的近路，能大大提高通信速度，减轻网络系统通信负荷，节约网络系统资源，提高网络系统畅通率。

路由器、交换机、集线器的区别

从物理上划分网段的交换机不同，路由器使用专门的软件协议从逻辑上对整个网络进行划分。

路由器是产生于交换机之后，就像交换机产生于集线器之后传统的交换机只能分割冲突域，不能分割广播域；而路由器可以分割广播域，由交换机连接的网段仍属于同一个广播域，广播数据包会在交换机连接的所有网段上传播，在某些情况下会导致通信拥挤和安全漏洞。连接到路由器上的网段会被分配成不同的广播域，广播数据不会穿过路由器。虽然第三层以上交换机具有VLAN功能，也可以分割广播域，但是各子广播域之间是不能通信交流的，它们之间的交流仍然需要路由器，同时路由器提供了防火墙的服务，路由器仅仅转发特定地址的数据包，不传送不支持路由协议的数据包传送和未知目标网络数据包的传送，从而可以防止广播风暴。

报文：网关：工作在第四层传输层及其以上

在浏览器中输⼊url地址会发生什么

查找域名IP地址（DNS协议）：分别从浏览器缓存路由器缓存 dns缓存中找

浏览器发送http请求（http tcp ip 协议）：与服务器建立tcp连接其中应用层 http 传输层 tcp 网络层 ip

路由器路由：用的OPSF协议

ARP 协议：路由器将ip地址转化为mac地址连接到服务器上

地址解析协议，即ARP（Address Resolution Protocol），是根据IP地址获取物理地址的一个TCP/IP协议。

服务器处理请求

服务器返回http响应

浏览器显示页面

TCP 三次握⼿和四次挥⼿

三次握手

SYN：同步序列编号(Synchronize Sequence Numbers)

在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接.

第一次握手：建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认；

第二次握手：服务器收到syn包,必须确认客户的SYN（ack=j+1）,同时自己也发送一个SYN包（syn=k）,即SYN+ACK包,此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN＋ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手.

为什么TCP客户端最后还要发送一次确认呢？

一句话，主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。

如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。

如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。

TCP 的四次挥手

以下描述不讨论序号和确认号，因为序号和确认号的规则比较简单。并且不讨论 ACK，因为 ACK 在连接建立之后都为 1。

A 发送连接释放报文，FIN=1。
B 收到之后发出确认，此时 TCP 属于半关闭状态，B 能向 A 发送数据但是 A 不能向 B 发送数据。
当 B 不再需要连接时，发送连接释放报文，FIN=1。
A 收到后发出确认，进入 TIME-WAIT 状态，等待 2 MSL（最大报文存活时间）后释放连接。
B 收到 A 的确认后释放连接。

四次挥手的原因

客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器会发送 FIN 连接释放报文。

为什么客户端最后还要等待2MSL（timewait状态）？

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

第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。

第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

另一个版本的答案

TIME_WAIT状态原理（很清楚）_落冰翼的博客-CSDN博客_time_wait

TCP/IP协议就是这样设计的，是不可避免的。主要有两个原因:

1）可靠地实现TCP全双工连接的终止

TCP协议在关闭连接的四次握手过程中，最终的ACK是由主动关闭连接的一端（后面统称A端）发出的，如果这个ACK丢失，对方（后面统称B端）将重发出最终的FIN，因此A端必须维护状态信息（TIME_WAIT）允许它重发最终的ACK。如果A端不维持TIME_WAIT状态，而是处于CLOSED 状态，那么A端将响应RST分节，B端收到后将此分节解释成一个错误（在java中会抛出connection reset的SocketException)。

因而，要实现TCP全双工连接的正常终止，必须处理终止过程中四个分节任何一个分节的丢失情况，主动关闭连接的A端必须维持TIME_WAIT状态。

2）允许老的重复分节在网络中消逝

TCP分节可能由于路由器异常而“迷途”，在迷途期间，TCP发送端可能因确认超时而重发这个分节，迷途的分节在路由器修复后也会被送到最终目的地，这个迟到的迷途分节到达时可能会引起问题。在关闭“前一个连接”之后，马上又重新建立起一个相同的IP和端口之间的“新连接”，“前一个连接”的迷途重复分组在“前一个连接”终止后到达，而被“新连接”收到了。为了避免这个情况，TCP协议不允许处于TIME_WAIT状态的连接启动一个新的可用连接，因为TIME_WAIT状态持续2MSL，就可以保证当成功建立一个新TCP连接的时候，来自旧连接重复分组已经在网络中消逝。

大量的 `TIME_WAIT` 状态 `TCP` 连接存在，其本质原因是什么？

大量的短连接存在
TCP 四次挥手关闭连接机制中，为了保证ACK 重发和丢弃延迟数据，设置time_wait为 2 倍的 MSL（报文最大存活时间）

TIME_WAIT状态：

TCP 连接中，主动关闭连接的一方出现的状态；（收到 FIN 命令，进入 TIME_WAIT 状态，并返回 ACK 命令）
保持 2 个 MSL 时间，即4 分钟；（MSL 为 2 分钟）

造成的问题：

每一个time_wait状态，都会占用一个「本地端口」，上限为65535(16 bit，2 Byte)；
当大量的连接处于 time_wait 时，新建立 TCP 连接会出错，address already in use : connect 异常

解决办法

启用长连接设置connection:keep-alive

在 HTTP 1.1 中所有的连接默认都是持续连接，除非特殊声明不支持。目前服务器端默认为 5-15 秒，可以设置。

以你的例子：一次请求了六个接口
如果开启HTTP持久连接，则此 6 个请求走同一条 TCP 连接，走同一条 HTTP 流。5 秒之内的所有请求都复用此 TCP 连接。当 5秒钟之内没有其他请求后，此连接断开。（一条长连接）
如果不HTTP持久连接，则此 6 个请求需要发起 6 条 TCP 连接（包括三次握手等），HTTP 请求后立刻断开，TCP 连接根据操作系统的释放规则进行释放。（6 条短连接）

开启后的优点：TCP 连接数比较少，所以随之而来和 TCP 相关的优点全都来了。其实和 HTTP 没什么关系，主要是大幅降低服务器端因大量新建 TCP 连接造成的 CPU负载包括端口占用，以及 TCP 传输相关的拥塞控制问题。

大量的close wait 如何解决

TCP通信过程中time_wait和close_wait产生过多的原因和解决方法_Kuany_的博客-CSDN博客_close wait 过多原因

close_wait过多原因

close_wait 按照正常操作的话应该很短暂的一个状态，接收到客户端的fin包并且回复客户端ack之后，会继续发送FIN包告知客户端关闭关闭连接，之后迁移到Last_ACK状态。但是close_wait过多只能说明没有迁移到Last_ACK，也就是服务端是否发送FIN包，只有发送FIN包才会发生迁移，所以问题定位在是否发送FIN包。FIN包的底层实现其实就是调用socket的close方法，这里的问题出在没有执行close方法。说明服务端socket忙于读写。

close_wait过多的解决方案

    代码层面做到
    第一：使用完socket调用close方法；
    第二：socket读控制，当读取的长度为0时（读到结尾），立即close；
    第三：如果read返回-1，出现错误，检查error返回码，有三种情况：INTR（被中断，可以继续读取），WOULDBLOCK（表示当前socket_fd文件描述符是非阻塞的，但是现在被阻塞了），AGAIN（表示现在没有数据稍后重新读取）。如果不是AGAIN，立即close
    可以设置TCP的连接时长keep_alive_time还有tcp监控连接的频率以及连接没有活动多长时间被迫断开连接