计算机网络的组成

计算机网络的分类

OSI七层模型

物理层
- 作用：该层为上层协议提供了一个传输数据的物理媒体
- 协议：EIA/TIA RS-232、EIA/TIA RS-449、V.35、RJ-45
数据链路层
- 作用：数据链路层在不可靠的物理介质上提供可靠的传输。该层的作用包括：物理地址寻址、数据的成帧、流量控制、数据的检错、重发等。
- 协议：ARP、RARP、MAC、SDLC、HDLC、PPP、STP、帧中继等
网络层
- 作用：网络层负责对子网间的数据包进行路由选择。网络层还可以实现拥塞控制、网际互连等功能。
- 协议：ARP、RARP、IP、IPX、RIP、OSPF等
传输层
- 作用：传输层是第一个端到端，即主机到主机的层次。传输层负责将上层数据分段并提供端到端的、可靠的或不可靠的传输。此外，传输层还要处理端到端的差错控制和流量控制问题。
- 协议：TCP、UDP、SPX等。
会话层
- 作用：会话层管理主机之间的会话进程，即负责建立、管理、终止进程之间的会话。会话层还利用在数据中插入校验点来实现数据的同步。
- 协议：RPC、SQL、NFS 、X WINDOWS、ASP
表示层
- 作用：表示层对上层数据或信息进行变换以保证一个主机应用层信息可以被另一个主机的应用程序理解。表示层的数据转换包括数据的加密、压缩、格式转换等。
- 协议：ASCII、PICT、TIFF、JPEG、 MIDI、MPEG
应用层
- 作用：应用层为操作系统或网络应用程序提供访问网络服务的接口。
- 协议：万维网、HTTP、FTP、SMTP

你知道的协议

TCP/UDP

TCP/UDP是什么？
TCP — Transmission Control Protocol，传输控制协议。
UDP — User Data Protocol，用户数据报协议。

TCP/UDP的区别（优缺点）？

preview

(1)、TCP是面向连接的，UDP是面向无连接的。TCP在通信之前必须通过三次握手机制与对方建立连接，而UDP通信不必与对方建立连接，不管对方的状态就直接把数据发送给对方
(2)、TCP连接过程耗时，UDP不耗时
(3)、TCP连接过程中出现的延时增加了被攻击的可能，安全性不高，而UDP不需要连接，安全性较高
(4)、TCP是可靠的，保证数据传输的正确性，不易丢包;UDP是不可靠的，易丢包
(5)、tcp传输速率较慢，实时性差，udp传输速率较快。tcp建立连接需要耗时，并且tcp首部信息太多，每次传输的有用信息较少，实时性差。
(6)、tcp是流模式，udp是数据包模式。tcp只要不超过缓冲区的大小就可以连续发送数据到缓冲区上，接收端只要缓冲区上有数据就可以读取，可以一次读取多个数据包，而udp一次只能读取一个数据包，数据包之间独立

TCP三次握手过程

STEP 1：主机A通过向主机B发送一个含有同步序列号的标志位的数据段给主机B，向主机B请求建立连接,通过这个数据段，主机A告诉主机B两件事:我想要和你通信；你可以用哪个序列号作为起始数据段来回应我。
STEP 2：主机B收到主机A的请求后,用一个带有确认应答(ACK)和同步序列号(SYN)标志位的数据段响应主机A，也告诉主机A两件事：我已经收到你的请求了，你可以传输数据了；你要用哪佧序列号作为起始数据段来回应我。
STEP 3：主机A收到这个数据段后，再发送一个确认应答，确认已收到主机B的数据段：”我已收到回复，我现在要开始传输实际数据了。这样3次握手就完成了，主机A和主机B就可以传输数据了。

preview

为什么需要三次握手？

我们假设client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。

本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。

假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。

所以，采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。

TCP四次挥手过程

当 TCP 数据段的传输结束时，双方都需要发送 FIN 段和 ACK 段来终止 TCP 会话。这个方式叫做四次挥手，详细过程如下：

主机 A 想要终止连接，发送序列号为 p 的段，FIN 置位，表示 FIN 管理段。
主机 B 收到主机 A 发送的 FIN 段后，发送 ACK 段，确认号为 p + 1 ，同时关闭连接。
主机 B 发送序列号为 q的段，FIN 置位，通知连接关闭。
主机 A 收到主机 B 发送的 FIN 段后，发送 ACK 段，确认号为 q + 1 ，同时关闭连接。TCP 连接至此结束。

注意
此时需要注意的是，TCP建立连接要进行3次握手，而断开连接要进行4次。
名词解释
ACK：TCP报头的控制位之一，对数据进行确认，确认由目的端发出，用它来告诉发送端这个序列号之前的数据段都收到了。比如，确认号为X，则表示前X-1个数据段都收到了，只有当ACK=1时，确认号才有效，当ACK=0时，确认号无效，这时会要求重传数据，保证数据的完整性。
SYN：同步序列号，TCP建立连接时将这个位置1。
FIN ：发送端完成发送任务位，当TCP完成数据传输需要断开时，提出断开连接的一方将这位置1。
为什么连接的时候是三次握手，关闭的时候却是四次握手？

建立连接时因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。所以建立连接只需要三次握手。

由于TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议，TCP是全双工模式。
这就意味着，关闭连接时，当Client端发出FIN报文段时，只是表示Client端告诉Server端数据已经发送完毕了。当Server端收到FIN报文并返回ACK报文段，表示它已经知道Client端没有数据发送了，但是Server端还是可以发送数据到Client端的，所以Server很可能并不会立即关闭SOCKET，直到Server端把数据也发送完毕。
当Server端也发送了FIN报文段时，这个时候就表示Server端也没有数据要发送了，就会告诉Client端，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。
为什么要等待2MSL？

MSL：报文段最大生存时间，它是任何报文段被丢弃前在网络内的最长时间。
有以下两个原因：
- 第一点：保证TCP协议的全双工连接能够可靠关闭：
  由于IP协议的不可靠性或者是其它网络原因，导致了Server端没有收到Client端的ACK报文，那么Server端就会在超时之后重新发送FIN，如果此时Client端的连接已经关闭处于CLOESD状态，那么重发的FIN就找不到对应的连接了，从而导致连接错乱，所以，Client端发送完最后的ACK不能直接进入CLOSED状态，而要保持TIME_WAIT，当再次收到FIN的收，能够保证对方收到ACK，最后正确关闭连接。
- 第二点：保证这次连接的重复数据段从网络中消失
  如果Client端发送最后的ACK直接进入CLOSED状态，然后又再向Server端发起一个新连接，这时不能保证新连接的与刚关闭的连接的端口号是不同的，也就是新连接和老连接的端口号可能一样了，那么就可能出现问题：如果前一次的连接某些数据滞留在网络中，这些延迟数据在建立新连接后到达Client端，由于新老连接的端口号和IP都一样，TCP协议就认为延迟数据是属于新连接的，新连接就会接收到脏数据，这样就会导致数据包混乱。所以TCP连接需要在TIME_WAIT状态等待2倍MSL，才能保证本次连接的所有数据在网络中消失。

TCP可靠性的四大手段

(1)、顺序编号：tcp在传输文件的时候，会将文件拆分为多个tcp数据包，每个装满的数据包大小大约在1k左右，tcp协议为保证可靠传输，会将这些数据包顺序编号

(2)、确认机制：当数据包成功的被发送方发送给接收方，接收方会根据tcp协议反馈给发送方一个成功接收的ACK信号，信号中包含了当前包的序号

(3)、超时重传：当发送方发送数据包给接收方时，会为每一个数据包设置一个定时器，当在设定的时间内，发送方仍没有收到接收方的ACK信号，会再次发送该数据包，直到收到接收方的ACK信号或者连接已断开

(4)、校验信息：tcp首部校验信息较多，udp首部校验信息较少。

流控制

接收端处于高负荷状态时，可能无法处理接收的数据，并丢弃数据，就会触发重发机制，导致网络流量无端浪费。

为了防止这种情况，TCP 提供一种机制可以让发送端根据接收端的实际接收能力控制发送的数据量，这就是流控制。它的具体操作是，接收端主机通知发送端主机自己可以接收数据的大小，于是发送端会发送不超过这个限度的数据。这个限度的大小就是窗口大小。

TCP 头部中有一个字段用来通知窗口大小。接收主机将缓冲区大小放入这个字段发送给接收端。当接收端的缓存不足或处理能力有限时，窗口大小的值会降低一半，从而控制数据发送量。也就是说，发送端主机会根据接收端主机的指示，对发送数据的量进行控制，也就形成了一个完整的 TCP 流控制。

若接收端要求窗口大小为 0 ，表示接收端已经接收全部数据，或者接收端应用程序没有时间读取数据，要求暂停发送。

如果窗口更新的报文丢失，可能会导致无法继续通信。为避免这个问题，发送端主机会时不时的发送一个叫窗口探测的数据段，此数据段仅含一个字节以获取最新的窗口大小信息。

拥塞控制

有了 TCP 的窗口控制，收发主机之间不再以一个数据段为单位发送确认应答，也能够连续发送大量数据包。在网络出现拥堵时，如果突然发送一个较大量的数据，有可能会导致整个网络瘫痪。

为了防止这个问题出现，在通信开始时，就会通过一个叫慢启动的算法得出的数值，对发送数据量进行控制。

为了在发送端调节发送数据的量，需要使用拥塞窗口。在慢启动时，将拥塞窗口的大小设置为 1 MSS 发送数据，之后每收到一次确认应答（ ACK ）,拥塞窗口的值就加 1 。在发送数据包时，将拥塞窗口的大小与接收端主机通知的窗口大小做比较，选择它们当中较小的值发送数据。这样可以有效减少通信开始时连续发包导致网络拥堵，还可以避免网络拥塞的发生。

TCP粘包，拆包问题

我们都知道TCP属于传输层的协议，传输层除了有TCP协议外还有UDP协议。那么UDP是否会发生粘包或拆包的现象呢？答案是不会。UDP是基于报文发送的，从UDP的帧结构可以看出，在UDP首部采用了16bit来指示UDP数据报文的长度，因此在应用层能很好的将不同的数据报文区分开，从而避免粘包和拆包的问题。而TCP是基于字节流的，虽然应用层和TCP传输层之间的数据交互是大小不等的数据块，但是TCP把这些数据块仅仅看成一连串无结构的字节流，没有边界；另外从TCP的帧结构也可以看出，在TCP的首部没有表示数据长度的字段，基于上面两点，在使用TCP传输数据时，才有粘包或者拆包现象发生的可能。

粘包、拆包发生原因

1、要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包。

2、待发送数据大于MSS（最大报文长度），TCP在传输前将进行拆包。

3、要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包。

4、接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包。

粘包、拆包解决办法

通过以上分析，我们清楚了粘包或拆包发生的原因，那么如何解决这个问题呢？解决问题的关键在于如何给每个数据包添加边界信息，常用的方法有如下几个：

1、发送端给每个数据包添加包首部，首部中应该至少包含数据包的长度，这样接收端在接收到数据后，通过读取包首部的长度字段，便知道每一个数据包的实际长度了。

2、发送端将每个数据包封装为固定长度（不够的可以通过补0填充），这样接收端每次从接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来。

3、可以在数据包之间设置边界，如添加特殊符号，这样，接收端通过这个边界就可以将不同的数据包拆分开。

如何区分通信的区别？

网络通信中通常采用 5 个信息来识别一个通信。它们是源 IP 地址、目的 IP 地址、协议号、源端口号、目的端口号。只要其中一项不同，就会认为是不同的通信。

ARP的工作原理如下（RARP工作原理与之相反）

首先，每台主机都会在自己的ARP缓冲区 (ARP Cache)中建立一个 ARP列表，以表示IP地址和MAC地址的对应关系。
当源主机需要将一个数据包要发送到目的主机时，会首先检查自己 ARP列表中是否存在该 IP地址对应的MAC地址，如果有﹐就直接将数据包发送到这个MAC地址；如果没有，就向本地网段发起一个ARP请求的广播包，查询此目的主机对应的MAC地址。此ARP请求数据包里包括源主机的IP地址、硬件地址、以及目的主机的IP地址。
网络中所有的主机收到这个ARP请求后，会检查数据包中的目的IP是否和自己的IP地址一致。如果不相同就忽略此数据包；如果相同，该主机首先将发送端的MAC地址和IP地址添加到自己的ARP列表中，如果ARP表中已经存在该IP的信息，则将其覆盖，然后给源主机发送一个 ARP响应数据包，告诉对方自己是它需要查找的MAC地址；
源主机收到这个ARP响应数据包后，将得到的目的主机的IP地址和MAC地址添加到自己的ARP列表中，并利用此信息开始数据的传输。如果源主机一直没有收到ARP响应数据包，表示ARP查询失败。