OSI 七层协议，TCP连接，可靠传输，流量控制，拥塞控制

OSI分层 （7层）：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。

TCP/IP分层（4层）：网络接口层、 网际层、运输层、 应用层。

五层协议 （5层）：物理层、数据链路层、网络层、运输层、 应用层。

各层协议的具体分工：
物理层：通过媒介传输比特,确定机械及电气规范以及原始比特流在物理媒体上的传输

数据链路层：将比特流组装成帧和点到点的传递（帧Frame) 帧中包含地址、控制、数据、校验码等信息。主要作用是通过校验、确认和反馈重发等手段，将不可靠的物理链路改造成对网络层来说无差错的数据链路，数据链路层还要协调收发双方的数据传输
速率，即进行流量控制。

网络层：数据以网络协议数据单元(分组)为单位进行传输，负责数据包从源到宿的传递和网际互连，这就需要在通信子网中进行路由选择。
相关协议：IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP
ICMP: 因特网控制报文协议,用于在IP主机、路由器之间传递控制消息。如ICMP差错报文[终点不可达，源点抑制，重定向..],ICMP询问报文。
ARP:地址解析协议,每个主机都会在自己的ARP缓冲区中建立一个ARP列表，以表示IP地址和MAC地址之间的对应关系。① 当源主机要发送数据时，首先检查ARP列表中是否有对应IP地址的目的主机的MAC地址，如果有，则直接发送数据。如果没有，就向本网段的所有主机发送ARP数据包。②当本网络的所有主机收到该ARP数据包时，首先检查数据包中的IP地址是否是自己的IP地址，如果不是，则忽略该数据包，如果是，则首先从数据包中取出源主机的IP和MAC地址写入到ARP列表中。然后将自己的MAC地址写入ARP响应包中，告诉源主机自己是它想要找的MAC地址。
RARP：逆地址解析协议，作用是完成硬件地址到IP地址的映射

传输层：是第一个端–端，也即主机–主机的层次。传输层提供的端到端的透明数据运输服务，使高层用户不必关心通信子网的存在。
TCP和UDP的区别：①TCP提供面向连接的、可靠的数据流传输，而UDP提供的是非面向连接的、不可靠的数据流传输。②TCP传输单位称为TCP报文段，UDP传输单位称为用户数据报。③TCP注重数据安全性，UDP数据传输快，因为不需要连接等待

会话层：是进程–进程的层次，其主要功能是组织和同步不同的主机上各种进程间的通信(也称为对话)。会话层负责在两个会话层实体之间进行对话连接的建立和拆除。
SQL/NFS(网络文件系统）/RPC(远程过程调用）

表示层：为上层用户提供共同的数据或信息的语法变化表示（对计算机内部不同的表示形式转化成统一的标准表示形式），如对数据进行翻译、加密和压缩
JPEG/MPEG

应用层：开放系统互连环境的最高层。不同的应用层为特定类型的网络应用提供访问 OSI 环境的手段。
UDP对应的协议：
（1） DNS：用于域名解析服务，将域名地址转换为IP地址。DNS用的是53号端口。
（2） SNMP：简单网络管理协议，使用161号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。
（3） TFTP(Trival File Transport Protocal)，简单文件传输协议，该协议在熟知端口69上使用UDP服务。
TCP对应的协议：
（1） FTP：定义了文件传输协议，使用21端口。
（2） Telnet：一种用于远程登陆的端口，使用23端口，用户可以以自己的身份远程连接到计算机上，可提供基于DOS模式下的通信服务。
（3） SMTP：邮件传送协议，用于发送邮件。服务器开放的是25号端口。
（4） POP3：它是和SMTP对应，POP3用于接收邮件。POP3协议所用的是110端口。
（5）HTTP：是从Web服务器传输超文本到本地浏览器的传送协议。

Socket

socket函数是操作系统内核将“TCP/IP协议栈 + 底层网卡”抽象出来的一个个用户友好的函数，用于操纵本地的“TCP/IP协议栈 + 底层网卡”与远端的服务器/主机完成通信的任务。

函数:
socket() – 创建套接字，它会创建一个结构体及收发缓冲区。此时并不指定该套接字在 哪个 IP 和 PORT 口上。
bind() – 用于将套接字绑定在特定的 IP 和 PORT 上。
listen(SOCKETs,intbacklog) – 用于为侦听端口创建两个队列用于接收客户 端的 SYN 请求，侦听客户端的 Socket 连接请求。backlog 指的就是已经完成握手了的队列的大小。
accept() — 将侦听端口中的 ESTABLISHED 队列中取出那些连接。 accept 函数返回的是 已建立连接的套接字描述符，包括客户端的 ip 和 port 信息，服务器的 ip 和 port 信息。
connect() – 客户端连接请求。
read()—- 负责从 fd 中读取内容。当读成功时，read 返回实际所读的字节数，如果返回的 值是 0 表示已经读到文件的结束了，小于 0 表示出现了错误。
write() —–将 buf 中的 nbytes 字节内容写入文件描述符 fd。成功时返回写的字节数。

客户端过程：socket() -> bind（）（可选的）->connect()
服务器过程：socket() -> bind（） -> listen() -> accept()

从图中可以看出，当客户端调用 connect()函数时，触发了连接请求，向服务器发送了 SYN J 包，这时 connect 进入阻塞状态（先调用 connect（）函数，然后发送 SYN 包）； 服务器监听到连接请求，即收到 SYN J 包，调用 accept()函数接收请求（先收到 SYN 包， 然后调用 accept()函数），向客户端发送 SYN K ，ACKJ+1，这时 accept 进入阻塞状态； 客户端收到服务器的 SYN K ，ACKJ+1 之后，这时 connect 返回，并对 SYN K 进行确认； 服务器收到 ACK K+1 时，accept 返回，至此三次握手完毕，连接建立。 总结：客户端的 connect()函数在三次握手的第二次之后返回，而服务器端的 accept （）在三次握手的第三次之后返回。

TCP的三次握手过程？为什么会采用三次握手

建立连接的过程是利用客户服务器模式，假设主机A为客户端，主机B为服务器端。

TCP的三次握手过程：主机A向B发送连接请求；主机B对收到的主机A的报文段进行确认；主机A再次对主机B的确认进行确认。
采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。失效的连接请求报文段是指：主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，主机A又重新向主机B发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B，主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发回确认，但是此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费。

四次挥手

与建立连接的“三次握手”类似，断开一个TCP连接则需要“四次握手”。
第一次挥手：主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不 会再给你发数据了
第二次挥手：被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1.
第三次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送
第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。

FIN_WAIT_1: 这个状态要好好解释一下，其实 FIN_WAIT_1 和 FIN_WAIT_2 状态的真 正含义都是表示等待对方的 FIN 报文。而这两种状态的区别是：FIN_WAIT_1 状态实际上 是当 SOCKET 在 ESTABLISHED 状态时，它想主动关闭连接，向对方发送了 FIN 报文， 此时该 SOCKET 即进入到 FIN_WAIT_1 状态。而当对方回应 ACK 报文后，则进入到 FIN_WAIT_2 状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应 ACK 报文，所以 FIN_WAIT_1 状态一般是比较难见到的，而 FIN_WAIT_2 状态还有时常常可以 用 netstat 看到。（主动方持有的状态）
FIN_WAIT_2： 上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET， 表示半连接，也即有一方要求 close 连接，但另外还告诉对方，我暂时还有点数据需要传 送给你(ACK 信息)，稍后再关闭连接。（主动方的状态）

TIME_WAIT: 表示收到了对方的 FIN 报文，并发送出了 ACK 报文，就等 2MSL 后即可 回到CLOSED可用状态了。 如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK 标志的报文时，可以直接进入到 TIME_WAIT 状态，而无须经过 FIN_WAIT_2 状态。（主 动方的状态）。

CLOSING（比较少见）: 表示双方同时关闭连接。如果双方几乎同时调用 close 函数， 那么会出现双方同时发送 FIN 报文的情况，就会出现 CLOSING 状态，表示双方都在关闭 连接。这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正 常情况下，当你发送 FIN 报文后，按理来说是应该先收到（或同时收到）对方的 ACK 报 文，再收到对方的 FIN 报文。但是 CLOSING 状态表示你发送 FIN 报文后，并没有收到对 方的 ACK 报文，反而却收到了对方的 FIN 报文。什么情况下会出现此种情况呢？其实细 想一下，也不难得出结论：那就是如果双方几乎在同时 close 一个 SOCKET 的话，那么 就出现了双方同时发送 FIN 报文的情况，也即会出现 CLOSING 状态，表示双方都正在关 闭 SOCKET 连接。

CLOSE_WAIT: 这种状态的含义其实是表示在被动房等待关闭。当对方 close 一个 SOCKET 后发送 FIN 报文给自己，你系统毫无疑问地会回应一个 ACK 报文给对方，此时则进入到 CLOSE_WAIT 状态。接下来，实际上你真正需要考虑的事情是察看你是否还有数据发送 给对方，如果没有的话，那么你也就可以 close 这个 SOCKET，发送 FIN 报文给对方， 也即关闭连接。所以你在 CLOSE_WAIT 状态下，需要完成的事情是等待你去关闭连接。

MAC表，ARP表，路由表

一：MAC地址表详解
说到MAC地址表，就不得不说一下交换机的工作原理了，因为交换机是根据MAC地址表转发数据帧的。在交换机中有一张记录着局域网主机MAC地址与交换机接口的对应关系的表，交换机就是根据这张表负责将数据帧传输到指定的主机上的。
二、ARP缓存表详解
上面我们讲解了交换机的工作原理，知道交换机是通过MAC地址通信的，但是我们是如何获得目标主机的MAC地址呢？这时我们就需要使用ARP协议了，在每台主机中都有一张ARP表，它记录着主机的IP地址和MAC地址的对应关系。
ARP协议：ARP协议是工作在网络层的协议，它负责将IP地址解析为MAC地址。
三、路由表
路由器负责不同网络之间的通信，路由器是工作在网络层的，在网络层可以识别逻辑地址。当路由器的某个接口收到一个包时，路由器会读取包中相应的目标的逻辑地址的网络部分，然后在路由表中进行查找。如果在路由表中找到目标地址的路由条目，则把包转发到路由器的相应接口，如果在路由表中没有找到目标地址的路由条目，那么，如果路由配置默认路由，如果没有配置默认路由，则将该包丢弃，并返回不可到达的信息

TCP可靠传输、流量控制和拥塞控制的实现

可靠传输：
1、在传递数据之前，会有三次握手来建立连接。
2、应用数据被分割成 TCP 认为最适合发送的数据块（按字节编号，合理分片）。这和 UDP 完全不同，应用程序产生的数据报长度将保持不变 。
3、当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不 能及时收到一个确认，将重发这个报文段
4、当 TCP 收到发自 TCP 连接另一端的数据，它将发送一个确认。这个确认不是立即发送， 通常将推迟几分之一秒 用于完整验证。
5、TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传 输过程中的任何变化。
6、.如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到 此报文段。 (校验出包有错，丢弃报文段，不给出响应，TCP 发送数据端，超时时会重发 数据)。(校验出包有错，丢弃报文段，不给出响应，TCP 发送数据端，超时时会重发 数据)

7、既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的到达可能会失序，因此 TCP 报 文段的到达也可能会失序。如果必要，TCP 将对收到的数据进行重新排序，将收到的数据 以正确的顺序交给应用层。 (对失序数据进行重新排序，然后才交给应用层)
8、既然 IP 数据报会发生重复，TCP 的接收端必须丢弃重复的数据。(对于重复数据，能够 丢弃重复数据)
流量控制：所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。利用滑动窗口实现流量控制。
9、TCP 还能提供拥塞控制。当网络拥塞时，减少数据的发送。

拥塞控制：

所谓拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。起初采用慢开始算法，当拥塞窗口达到门限值时候，则采用拥塞避免算法。无论是慢开始还是拥塞避免算法，只要出现了网络拥塞则将门阀值降低为当前窗口值一般，并且将拥塞窗口值重新设置为1。下面进行详细的介绍。

旧版本的拥塞控制机制：
l慢开始：慢开始的“慢”并不是指增长速率的慢，而是指在TCP开始发送报文段时先设置拥塞窗口为1。

l 拥塞避免： 使拥塞窗口按线性规律增长。

TCP Reno版本中的拥塞控制：
l 快重传： 发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待为其设置的重传计时器到期。
例子：假设有4，5，6三个待接收的数据包，先收到了5,6，协议栈是不会回复对5,6包的确认，而是根据TCP协议的规定，当接收方收到乱序片段时，需要重复发送ACK, 在这个地方会发送报文4 seq的ACK，表明需要报文4没有被接收到，如果此后收到的是报文7，那么仍然要回报文4 seq的ACK，如果连续发送3个 dup ACK，接收端认为这个片段已经丢失，进行快速重传

l 快恢复(与快重传配合使用)：当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把慢开始门限减半。这是为了预防网络发生拥塞。请注意，接下来不执行慢开始算法。

TCP 建立连接之后怎么保持连接（检测连接断没断）？

有两种技术可以运用。一种是由 TCP 协议层实现的 Keepalive 机制，另一种是由应用 层自己实现的 HeartBeat 心跳包。
1.在 TCP 中有一个 Keep-alive 的机制可以检测死连接，原理很简单，当连接闲置一定 的时间（参数值可以设置，默认是 2 小时）之后，TCP 协议会向对方发一个 keepalive 探 针包（包内没有数据），对方在收到包以后，如果连接一切正常，应该回复一个 ACK；如 果连接出现错误了（例如对方重启了，连接状态丢失），则应当回复一个 RST；如果对方 没有回复，那么，服务器每隔一定的时间（参数值可以设置）再发送 keepalive 探针包， 如果连续多个包（参数值可以设置）都被无视了，说明连接被断开了。
2.心跳包之所以叫心跳包是因为：它像心跳一样每隔固定时间发一次，以此来告诉服 务器，这个客户端还活着。事实上这是为了保持长连接，至于这个包的内容，是没有什么 特别规定的，不过一般都是很小的包，或者只包含包头的一个空包。由应用程序自己发送 心跳包来检测连接的健康性。客户端可以在一个 Timer 中或低级别的线程中定时向服务器 发送一个短小精悍的包，并等待服务器的回应。客户端程序在一定时间内没有收到服务器 回应即认为连接不可用，同样，服务器在一定时间内没有收到客户端的心跳包则认为客户 端已经掉线。