计算机网络知识随记之基础篇

最新推荐文章于 2024-11-10 22:52:20 发布

weixin_34218579

最新推荐文章于 2024-11-10 22:52:20 发布

阅读量119

点赞数

文章标签：网络运维 java

原文链接：https://segmentfault.com/a/1190000002537066

版权

原文链接
本篇主要讲解网络的基础知识，从tcp/ip协议栈讲起，不会讲解的太深，权作自己的笔记，有问题的地方希望大家可以留言指出。

协议栈

这里主要讲解TCP/IP协议栈，不再讲解其与OSI协议栈的区别。

TCP/IP协议分为4层，由上至下为应用层、传输层、网络层和网络接口层。

应用层：定义上层应用可以直接使用的高级协议，如http、ftp等。
传输层：定义控制数据传输的协议，用以保证数据的可靠性和顺序到达性等，如tcp、udp协议。
网络层：定义不同网络类型间通信的协议，如IP协议用于实现网际路由，ICMP协议用于检测网络的畅通性，ARP协议用于获取设备MAC地址等。
网络接口层：定义网络介质上的传输协议，和电气相关，如Ethernet协议、802.3协议等，主要由操作系统的网卡驱动程序实现。

四层由上到下逐层依赖，用户数据也在每一层被添加进不同的头部，以便进行传输和解析，封装过程大致如图：

图1

下面我自上而下详细讲解下每一层的作用和数据封装内容。

应用层

该层主要涉及一些高级协议，像大家耳熟能详的http协议、ftp协议等等，每一个协议都能单独开几篇文章来讲了，这里就不赘述了。

传输层

该层主要是对应用层的数据进行分割和重装，提供端到端的服务。主要有UDP和TCP两种协议，下面分别讲解这两种协议。

UDP

UDP即User Datagram，用户数据报协议，从名字上会联系到IP Datagram，即Ip数据报，两者也确实有关联。在UDP被并入TCP/UDP协议簇之前，是作为IP协议的上层抽象存在的，它的名字也是源于IP Datagram，前面加上User便有了端到端的意味。图2展示了UDP的包结构。

图2

UDP的首部只占用8个字节，顶部的12个字节的伪首部是用于计算UDP首部检验和。所谓“伪”是指这个首部只是拿来用下，并不出现在实际传送的数据中。UDP可以依据伪首部计算出来的检验和来判断数据包是否正确到达目的地，即如果传输过程中该数据包中伪首部设计的数据发生变化，那么该数据包会被视为非法包，被丢弃。

IP地址不是在IP层获取的吗？而它对上层的UDP不是应该透明吗？
分层只是一个逻辑上的理想化模型，在实际实现中，为了效率等，UDP的检验和其实就是通过IP层来计算获取的。

UDP是面向报文的，没有可靠性控制，没有拥塞控制，无连接，所以其开销小，但网络环境差或者发送数据过大时导致ip分片过多，导致发送率降低，影响程序的使用。为了提高UDP的发送率，应该尽量使得UDP可以使用一个IP数据报就能发送出去，这里就涉及到MTU(下文会详细讲解)。

UDP推荐传送的数据大小为1500(以太网的MTU)-20(ip数据报首部)-8(udp首部)=1472字节。

TCP

TCP即Transportation Control Protocol，传输控制协议，提供了一种可靠的面向连接的字节流传输层服务。TCP协议相对复杂，主要知识点有三次握手建立连接、四次握手关闭连接、滑动窗口协议、拥塞控制策略、Nagle算法等等，这里只做简单介绍，基本一带而过，感兴趣的可以去详细研究。图3展示了tcp报文段(segment)的格式。

图3

源端口号和目的端口号是用于区分进程用的，序号和确认号是用于握手的凭证。4bit的首位长度(单位是4Byte)表明tcp首部最大为15*4Byte=60byte。后面的标志位有几个要讲解下：

ACK: ACK=1表示该报文段中有确认号需要处理。
PSH: PSH=1表示该报文段中有数据需要处理。
RST: RST=1表示到目的端的连接出问题了，需要上层做出处理，如重新建立连接等。
SYN: SYN=1 ACK=0表明是建立连接请求报文段，SYN=1 ACK=1表明同意建立连接报文。
FIN: FIN=1表示对端的数据已经发送完毕，要求释放连接。

窗口大小是用来实现滑动窗口协议的，用来加快tcp数据的传输。

下面我们来看看建立连接的示意图。

三次握手的过程上图已经详细地描述了，这里说一下第三次握手的必要性，即发送方在收到接收方的ack后又主动发送了一次ack给接收方。原因是为了避免一种异常情况：在网络不稳定的情况下，发送方发出的一个连接请求经过在某个网络中间节点滞留，等其到达接收端时正常的通信早已结束，但接收方不知道，所以它会立刻发送一个ack给发送方，如果此时没有第三次握手的确认，那么服务端会认为该连接有效，造成资源的浪费。

下面再看一下关闭链接的示意图。

四次握手的过程上图已经详细的描述了，这里说一下TIME_WAIT这个状态，为什么会有一个2MSL的时间存在？MSL 即Max Segment LifeTime，一个报文段的最长生存时间。2MSL便是用来保证A发送的最后一个ack可以到达B，如果没有到达B，B会超时重发ACK和FIN报文，此时A也可以收到该报文，然后重新发送ack，以保证四次握手的完整性。当然关于TIME_WAIT是许多服务器运维人员的心头痛，因为它会占据着一个端口不释放，浪费资源，后面再写文章专门聊下TIME_WAIT吧。

TCP的状态迁移见下图。

上面这张图基本阐述了每个状态的迁移时机，这是一个有限状态机表现方式。看懂了这个图，tcp也算是入门了。

关于传输层想了解更多的话，可以好好阅读下这篇文章。

网络层

网络层也常叫IP层，因为这一层最重要的协议就是IP协议，用于网际路由，提供不可靠无连接的数据报传送服务，该层的数据传送单位为IP数据报(IP datagram)。

其协议格式如下图所示。

这里简单介绍几个部分。

首部长度同tcp一样，最大表示15*4Byte=60Byte。
总长度(16bit)是指整个ip数据报的长度，表示最大值为64K，也就是说IP报是有最大传输限定值的。
标识字段用于唯一的表示一次数据传输。
标志位(3bit)用于表示是否可以分片或者是否有其他分片。
片偏移(13bit)用于切片时的片偏移。

这里详细讲解下IP分片。IP数据报下一层要通过数据链路层封装成帧发送出去，但帧大小受网络设备电气属性影响是有限制的，即MTU，不同的网络拓扑和设备的MTU也不同，如以太网是1500字节。如果IP数据报大于MTU，那么它必须分片才能实现数据的传送，分片发生在各个网络设备上，在目的主机参照标识字段、标志位和片偏移来实现重组。值得注意的是，ip分片传输后，标识字段都被复制到每一个分片上，而总长度也变为该片的长度。优点是IP数据报可以穿过复杂多变的网络环境，缺点是一个分片丢失，该数据报就发送失败，增大了丢包的概率。

网络层另一个重要的协议是ICMP(Internet Control Message Protocol)协议，其提供了一套查找网络故障的机制，有差错报文和控制报文，可用于检查主机不可达、中间路由出问题、网络拥塞等问题，不同的问题会返回不同的错误类型。ICMP的功能只是报告问题而不能纠正错误。ping命令使用控制报文中的回显请求和应答来实现的，traceroute是使用差错报文中的TTL超时报文和目标不可达报文实现的。

网络层还有ARP和RARP协议用于在IP和MAC地址之间转换，这里就不详细讲解了。

另外这篇文章详细地讲述了IP数据报分片是如何在局域网和广域网中传递的，感兴趣的可以去详细看下。

网络接口层

tcp/ip的网络接口层对应OSI模型中的链路层和物理层，其传输的数据单位是帧(Frame)。在上层要发送的数据包的首部和尾部添加相关数据后封装成帧后发送出去，其主要有如下三个作用：

为网络层接收和发送ip数据报(IP datagram)。
为arp发送请求和接收数据。
为rarp发送请求和接收数据。

网络接口层协议有Ethernet协议、802.3等等，如下图展示了这两种协议的组成部分。

该层首部通常包含目的和源地址，就是设备的mac地址，尾部是一个CRC校验码，用于保证数据的准确性。详细介绍可以去参考这篇文章。

细心的同学应该观察到中间传输的数据域是有长度限制的，如802.3是从38到1492，ethernet协议是从46到1500。这里数据长度的限制是由传输介质的物理特性决定的，如果传输的数据长度不在该范围内，则该帧会被丢弃。这里就是MTU的出处了。

MTU(Maximal Transmission Unit)，最大传输单位值，即可以一次性传输数据的最大值，该值往往受传输介质约束。在以太网协议中，MTU值为1500.一个帧的构成为7字节前导同步吗＋1字节帧开始定界符＋6字节的目的MAC＋6字节的源MAC＋2字节的帧类型＋1500＋4字节的FCS(校验码),最大值为1526。其实通过抓包工具获取的一个帧最大却是1514，原因在于数据帧到达网卡后，在物理层网卡会先去掉前导同步码和帧开始定界符，之后根据FCS进行验证，如果失败则丢弃该帧，否则就检查目的MAC地址是否符合自己的接收条件（MAC地址和自己的匹配、广播地址等等），如果符合，将该帧交设备驱动程序做进一步的处理，这个时候抓包工具才能抓到包，此时的帧也被去除了校验码，所以最终抓到的帧大小为6+6+2+1500=1514。传输数据有最大值也有最小值，当上层传输的数据小于最小值时(ethernet时46)，比如tcp三次握手时的ack返回仅有20（tcp头部）+20(ip头部)=40字节，小于最小值46字节。对于此种情况，网卡驱动程序会进行自动填充，但如果抓包工具如果先于驱动程序抓到该帧，那么其大小就要取决于抓包工具本身的显示，wireshark只是显示原大小。

上面对于链路层中的包长度进行了简单地说明，感兴趣的同学可以去查看这篇文章。

至此，TCP/IP的网络协议栈大致简单地进行了讲解，下面就再以问答的形式讲解几个知识点。

MTU是什么？MSS是什么？两者有什么关系吗？

答：MTU即Maximal Transmission Unit，最大传输单元，是指网络接口层中由于受传输介质的物理特性制约一次可以传送的最大字节数，如以太网中MTU为1500Byte。MTU可以由人为修改，从而达到最优网络传输效率。
MSS即Maximal Segment Size，最大段长度，是传输层中TCP报文段中数据段的最大长度，默认是536Byte。其存在的意义如下：

防止传输数据过小造成资源浪费。比如发送数据每次都是1Byte，在每一层都会添加首部（20Byte的TCP首部和20Byte的IP首部），之后才会完成发送。也就是说传送的41Byte中，只有1Byte是有效数据，这明显造成了资源的浪费。
防止传输数据过大造成传输效率降低。如果发送的数据过大，超过了MTU的值，那么在IP层就会出现分片现象，而接收方也要耗费更多的资源和时间来处理分片，如果在传输过程中发生丢片，也会进一步增大网络开销。

有了MSS，TCP每次传输的数据都能被控制在一个合理的范围内，避免IP分片的发生，增大传输效率，最大化利用资源。

下图描述了MTU和MSS的关系，可以简单地理解为MTU=IP Header + TCP Header + MSS。

下面这张图描述了TCP是如何在三次握手建立连接的过程中和对方协商MSS大小的。注意MSS只会出现在SYN包中。

什么是半连接？SYN Flood是怎么一回事？
答：所谓半连接，顾名思义就是还没有完成三次握手建立连接。具体是指服务端在收到客户端的SYN包后，会据此生成一个半连接的对象，并将其存储在一个半连接队列(SYN Queue)中进行维护。一旦收到客户端的ACK包后会将该对象从半连接队列(SYN Queue)转移到已连接队列(Accept Queue)中等待accept系统调用。一经accept调用，数据的传输和接收才会正式开始。队列肯定是不能无限长的，因为每个对象都会占据存储资源，内核配置中有两个参数对应这两个队列的长度。

/proc/sys/net/ipv4/tcp_max_syn_backlog，该参数指定了半连接队列的最大长度，队列达到该值时，后续的SYN请求会被拒绝。可以通过sysctl进行配置。
sk_max_ack_backlog，该参数指定了已连接队列的最大长度，队列达到该长度时，后续的连接请求会被拒绝。该参数一般是在listen系统调用中指定的，如listen(int sockfd,int backlog) 中第二个参数。

SYN FLood攻击便是利用了半连接队列的长度限制来完成攻击的。攻击策略为伪造大量SYN包发送给服务端，但不返回ACK包，导致服务端半连接队列被迅速占满，正常的连接被抛弃。服务端会有大量处于SYN_RECV状态的连接，其会尝试重发ACK包给实际不存在的客户端，导致CPU满负载，内存耗尽，从而达到攻击效果。

一般可以通过修改net.ipv4.tcp_synack_retries 来减少重试发送ack的次数、开启 net.ipv4.tcp_syncookies、调大net.ipv4.tcp_max_syn_backlog来进行防御。

下面两篇文章对半连接都进行了很详细的讲解，感兴趣的可以去查看：文章一和文章二。
阿里云在2014年春节期间遭遇过SYN Flood攻击，感兴趣的也可以去看下相关介绍。

什么是粘包？怎么解决？
答：粘包是指服务端收到的数据出现不完整、混乱等情况。

粘包出现的原因是TCP数据的“流”特性。所谓“流”是指tcp传输的数据并不会在逻辑上进行划分，比如客户端给服务端发送了A和B两份数据，tcp发送的时候并不是分两次先发A数据，再发B数据，而是可能出现下面的情况：

先发送A和B的一部分，再发送B剩余部分

先发送A的一部分，再发送A剩余部分和B

可能有人会问，我们在编程的时候不是直接调用了send(byte[])了吗？为什么数据会出现这种混乱的发送情况，原因有两个：

如果开启了Nagle算法，即tcp_no_delay是false，那么即便调用了send方法，tcp也不一定会立即将数据发送出去，而是会等待其他数据一同发送，这样做是为了最大化利用网络资源。

如果发送的数据过大，超过了MSS的大小，tcp会对数据进行分段发送，此时也不可能一次性将数据发送完毕。

这个时候服务端接收数据时该如何把A和B区分开呢？如果只是单纯地将一次接收的数据作为完整数据(A或B)处理，很容易出错。这里就引出了封包和拆包的概念。

所谓封包，就是将要传送的数据按照一个可辨识的结构传输，比如客户端和服务端约定传递的数据都遵从 字节长度(4Byte)+实际数据 的规则，那么服务端在解析数据(即拆包)的时候，就可以先读取4Byte，获取到一个完整数据的实际长度，然后再读取该长度的数据，之后再交由上层处理。
关于封包和拆包，感兴趣的可以去看下面这篇文章。

socket的close和shutdown有区别吗？

答：有区别。

这个涉及到tcp关闭连接的方式，主要由两种：

一种是正常的通过4次握手关闭，这是优雅的方式，可以保证双方的数据都被接受。

一种是通过发送RST包的方式跳过4次握手快速关闭连接，这是暴力的方式，不安全。

close会直接关闭socket的文件描述符，包括输入和输出流，但shutdown只是在己方的输入输出流上做了一些人为的处理，比如丢弃了输入流中的数据，直接返回EOF结束符和向输出流写入东西时报错等等，但并不会关闭socket，所以对方的连接依然可以正常读写，要关闭还是要调用close。

另外close只会关闭本进程的socket文件描述符，如果其还被其他进程调用，则实际不会被关闭。但shutdown却会影响所有使用了该socket的进程。无特殊情况，使用close关闭socket即可。
在shutdownOutput后，再写入时会报broken pipe的错误。对执行了close的socket读入时会报错：socket closed。详情可以参考这篇文章。

flush有必要吗？

答：基本无必要。

我们在使用文件流的时候，都会强调一下flush函数，有时如果不主动调用，会导致写入的数据没有写到磁盘上，造成数据丢失。那么socket编程中是否要注意flush呢？

实际上当我们socketOutputStream.write(byte[])(java接口)的时候，数据已经发送出去，与flush无关。当然如果你在outputstream的外层套一层buffer，比如在SocketOutPutStream外层包一个BufferedOutPutStream，其内部会有自己的缓存，这个时候flush就有必要了，因为buffer相当于在jvm层做了一层缓存，直到调用flush函数，数据才会被写出。

进程在意外停止的时候，其关联的socket会关闭吗？

答：会关闭。

在linux系统中，是回这样的。当进程意外中止或者被kill的时候，系统会直接调用相关socket的close函数，单方面关闭socket链接并且不等待对方关闭，会直接给对方发送RST包。可以参考这篇文章。