TCP/IP四层模型和OSI七层模型的概念

osi（Open System Interconnection Reference Model）

osi7层模型，分别是

第7层 应用层（Application Layer）
提供为应用软件而设的界面，以设置与另一应用软件之间的通信。例如：HTTP,HTTPS，FTP，TELNET，SSH，SMTP，POP3等。

第6层 表示层（Presentation Layer）
把数据转换为能与接收者的系统格式兼容并适合传输的格式。

第5层 会话层（Session Layer）
负责在数据传输中设置和维护电脑网络中两台电脑之间的通信连接

第4层 传输层（Transport Layer）
把传输表头（TH）加至数据以形成数据报。传输表头包含了所使用的协议等发送信息。例如：传输控制协议义（TCP）等

第3层 网络层（Network Layer）
决定数据的路径选择和转寄，它网络表头（NH）加至数据报，以形成数据包。网络表头包含了网络数据。例如：互联网协议（IP）等，网关，多口网关（路由器）

第2层 数据链路层（Data link Layer）
负责网络寻址、错误侦测和改错。当表头和表尾被加至数据包时，会形成了帧。数据链表头（DLH）是包含了物理地址和错误侦测及改错的方法。数据链表尾（DLT）是一串指示数据包末端的字符串。例如以太网、无线兼容认证券市场（Wi-Fi）和通用分组无线服务（GPRS）等。

第1层 物理层（Physical Layer）
在局部局域网络上传送帧，它负责管理电脑通信设备和网络媒体之间的互通。包括了针脚、电压、线缆规范、集线器、中继器、网卡、主机适配器等。

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

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



应用层：

该层主要涉及一些高级协议，像大家耳熟的http协议、ftp协议等。

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

UDP
UDP即User Datagram，用户数据报协议，从名字上会联系到IP Datagram，即ip数据报，两者也确实有关联。在UDP被并入TCP/UDP协议簇之前，是作为IP协议的上层抽象存在的，它的名字也是源于IP Datagram，前面加上User 便有了端到端的意味。图2展示了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算法等等。下图展示了tcp报文段（segment）的格式。



源端口号和目的端口号是用于区分进程用的，序号和确认号是用于握手的凭证。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是许多服务器运维人员的心头痛，因为它会占据着一个端口不释放，浪费资源。
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地址之间转换。

网络接口层
tcp/ip的网络接口层对应OSI模型中的链路层和物理层，其传输的数据单位是帧（Frame）。在上层要发送的数据包的首部和尾部添加相关数据后封装成帧后发送出去，其主要有如下三个作用：
1、为网络层接收和发送ip数据报（IP datagram）。
2、为arp发送请求和接收数据。
3、为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进行验证，如果符合，将该帧交互设备驱动程序做进一步的处理，这个时候抓包工具才能抓到包，此时的帧也被去除了校验码，所以最终抓到的帧大小为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。
MSS即Maximal Segment Size，最大段长度，是传输层中TCP报文段中数据段的最大长度，默认是536Byte。其存在的意义如下：
防止传输数据过小造成资源浪费。比如发送数据每次都是1Byte，在每一层都会添加首部（20Byte的TCP首部和20Byte的IP首部），之后才会完成发送。也就是说传送的41Byte中，只有1Byte是有效数据，这明显造成了资源的浪费。
防止传输数据过大造成传输效率降低。如果发送的数据过大，超过了MTU的值，那么在IP层就会出现分片现象，而接收方也要耗费更多的资源和时间来处理分片，如果在传输过程中发生丢片，也会进一步增大网络开销。
防止传输数据过大造成传输效率降低。如果发送的数据过大，超过了MTU的值，那么在IP层就会出现分片现象，而接收方也要耗费更多的资源和时间来处理分片，如果在传输过程中发生丢片，也会进一步增大网络开销。

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

下图描述了MTU和MSS的关系，可以简单地理解为MTU=IPHeader + 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来进行防御。

***什么是粘包？怎么解决？
粘包是指服务端收到的数据出现不完整、混乱等情况。
粘包出现的原因是TCP数据的“流”特性。所谓“流”是指tcp传输的数据并不会在逻辑上进行划分，比如客户端给服务端发送了A和B两份数据，tcp发送的时候并不是分两次先发A数据，再发B数据，而是可能出现下面的情况：
1、先发送A和B的一部分，再发送B剩余部分
2、先发送A的一部分，再发送A剩余部分和B

可能有人问，我们在编程的时候不是直接调用了send(byte[])了吗？为什么数据会出现这种混乱的发送情况，原因有两个：
1、如果开启了Nagle算法，即tcp_no_delay是false，那么即便调用了send方法，tcp也不一定会立即将数据发送出去，而是会等待其他数据一同发送，这样做是为了最大化利用网络资源。
2、如果发送的数据过大，超过了MSS的大小，tcp会对数据进行分段发送，此时也不可能一次性将数据发送完毕。

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

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

***socket的close和shutdown有区别吗？
有区别，这个设计到tcp关闭连接的方式，主要有两种：
1、一种是正常的通过4次握手关闭，这是优雅的方式，可以保证双方的数据都被接受。
2、一种是通过发送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包。