敖丙思维导图-网络基础

敖丙思维导图系列目录

这些知识整理都是自己查阅帅丙资料（当然还有其他渠道）加以总结滴~ 每周都会更新知识进去。
如有不全或错误还请大家在评论中指出~

---

1. 敖丙思维导图-集合
2. 敖丙思维导图-多线程之synchronized\ThreadLocal\Lock\Volatitle\线程池
3. 敖丙思维导图-JVM知识整理
4. 敖丙思维导图-Spring
5. 敖丙思维导图-Redis
6. 敖丙思维导图-RocketMQ+Zookeeper
7. 敖丙思维导图-Mysql数据库
8. 敖丙思维导图-网络基础

---

以下大部分来自傲丙的blog

Linux查看网络状态

netstat 用于显示各种网络相关信息（网络连接，路由表，接口状态，无效连接，组播成员）

// 查看网络链接状况
netstat -tlunp

Recv-Q（网络接收队列）：表示收到的数据已经在本地接收缓冲，但是还有多少没有被进程取走，recv()
Send-Q（网络发送队列）：对方没有收到的数据或者说没有Ack的,还是本地缓冲区.
通过netstat的这两个值就可以简单判断程序收不到包到底是包没到还是包没有被进程recv。

这两个值通常应该为0，如果不为0可能是有问题的。packets在两个队列里都不应该有堆积状态。可接受短暂的非0情况。如文中的示例，短暂的Send-Q队列发送pakets非0是正常状态。

如果接收队列 Recv-Q 一直处于阻塞状态，可能是遭受了拒绝 服务 denial-of-service 攻击。
如果发送队列 Send-Q 不能很快的清零，可能是有应用向外发送数据包过快，或者是对方接收数据包不够快。

-a:　　列出系统中所有网络连接，包括已经连接的网络服务、监听的网络服务和Socket套接字
-t：　　列出TCP数据
-u：　　列出UDP数据
-l：　　列出正在监听的网络服务（不包含已经连接的网路服务）
-n：　　用端口显示服务，而不用服务名
-p：　　列出该服务的进程ID(PID)

tcpdump

tcpdump只能抓取流经本机的数据包。

lsof （列出被进程所打开的文件的信息）

• 列出谁在使用某个特定的udp端口 lsof -i udp:55
• 通过某个进程号显示该进行打开的文件 lsof -p 1

ss （获取socket统计信息）

可以显示和netstat类似的内容。但是ss的优势在于它能够显示更详细的有关网络连接的状态信息，而比netstat更快速、更高效。

查看当前服务器的网络连接数
ss -s

查看所有打开的网络端口
ss -l

ss -ta   #查看TCP socket

TCP/IP

TCP/IP 概念层模型

1. 应用层 （FTP、HTTP）
2. 传输层：提供端对端的接口（TCP、UDP）
3. 网络层 ：为数据包选择路由(IP)
4. 数据链路层：传输有地址的数据帧+错误检测（ARP）

首先要看TCP/IP协议，涉及到四层：链路层，网络层，传输层，应用层。 　　
其中以太网（Ethernet）的数据帧在链路层 　　
IP包在网络层 　　
TCP或UDP包在传输层 　　
TCP或UDP中的数据（Data)在应用层 　　
它们的关系是 数据帧｛IP包｛TCP或UDP包｛Data｝｝｝

我的链接-TCP&UDP

TCP概述

• TCP协议是面向连接的传输层协议
• 提供可靠交付
• 使用全双工通信
• 面向字节流

TCP数据报

-「窗口」：窗口字段明确指出了现在允许对方发送的数据量。窗口值经常在动态变化着 窗口指的是发送本报文段的一方的接收窗口（而不是自己的发送窗口）。
-「确认ACK」：仅当ACK=1时确认号字段才有效。当ACK=0时，确认号无效。TCP规定，在连接建立后所有传送的报文段都必须把ACK置1。

TCP重传机制

TCP 实现可靠传输的方式之一，是通过序列号（SYN）与确认应答(ACK)

1. 超时重传
   超时重传时间 RTO 的值应该略大于报文往返 RTT 的值。如果超时重发的数据，再次超时的时候，又需要重传的时候，TCP 的策略是超时间隔加倍。也就是每当遇到一次超时重传的时候，都会将下一次超时时间间隔设为先前值的两倍。两次超时，就说明网络环境差，不宜频繁反复发送。
2. 快速重传
   它不以时间为驱动，而是以数据驱动重传。快速重传的工作方式是当收到三个相同的 ACK 报文时，会在定时器过期之前，重传丢失的报文段。快速重传机制只解决了一个问题，就是超时时间的问题，但是它依然面临着另外一个问题。就是重传的时候，是重传之前的一个，还是重传所有的问题。
3. SACK (选择性确认)
   在 TCP 头部「选项」字段里加一个 SACK 的东西，它可以将缓存的地图发送给发送方，这样发送方就可以知道哪些数据收到了，哪些数据没收到，知道了这些信息，就可以只重传丢失的数据。
4. D-SACK
   使用了 SACK 来告诉「发送方」有哪些数据被重复接收了。

滑动窗口

tcp使用滑动窗口做流量控制与乱序重排。tcp传输可靠性来源于确认重传机制，tcp滑动窗口的可靠性也是建立在确认重传机制上的。

接收端会给发送端一个负反馈，通过这个负反馈可以控制发送端的滑动窗口的大小。

流量控制

TCP 提供一种机制可以让「发送方」根据「接收方」的实际接收能力控制发送的数据量，这就是所谓的流量控制。

拥塞控制

在网络出现拥堵时，如果继续发送大量数据包，可能会导致数据包时延、丢失等，这时 TCP 就会重传数据，但是一重传就会导致网络的负担更重，于是会导致更大的延迟以及更多的丢包，这个情况就会进入恶性循环被不断地放大….拥塞控制的目的就是避免「发送方」的数据填满整个网络。
拥塞窗口 cwnd是发送方维护的一个 的状态变量，它会根据网络的拥塞程度动态变化的。

1. 慢启动
   一点一点的提高发送数据包的数量。当发送方每收到一个 ACK，就拥塞窗口 cwnd 的大小就会加 1。
   当达到慢启动门限时，切换拥塞避免

慢启动值得就是一条TCP链接刚建立时不要一下发送大量数据导致网络拥塞激增，而是由小到大根据反馈逐渐增大拥塞窗口。

2. 拥塞避免
   拥塞避免算法就是将原本慢启动算法的指数增长变成了线性增长。每当收到一个 ACK 时，cwnd 增加 1/cwnd。
   就这么一直增长着后，网络就会慢慢进入了拥塞的状况了，于是就会出现丢包现象，这时就需要对丢失的数据包进行重传。当触发了重传机制，也就进入了「拥塞发生算法」。

拥塞避免就是让滑动窗口缓慢增大，而不是像慢开始那样成倍增长。

3. 拥塞发生
   当网络出现拥塞，也就是会发生数据包重传，重传机制主要有两种：

• 超时重传 (ssthresh慢启动门限 设为 cwnd/2，cwnd 重置为 1) 后，就重新开始慢启动，慢启动是会突然减少数据流的。但是这种方式太激进了，反应也很强烈，会造成网络卡顿。
• 快重传(cwnd = cwnd/2 ，也就是设置为原来的一半;ssthresh慢启动门限 = cwnd;) 进入快速恢复算法

发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器到期。

4. 快恢复

• 拥塞窗口 cwnd = ssthresh + 3 （ 3 的意思是确认有 3 个数据包被收到了）
• 重传丢失的数据包
• 如果再收到重复的 ACK，那么 cwnd 增加 1
• 如果收到新数据的 ACK 后，设置 cwnd 为 ssthresh，接着就进入了拥塞避免算法

当发送方连续收到三个重复确认时，就执行 “乘法减小” 算法，把慢开始门限减半。这是为了预防网络发生拥塞。注意，接下去不执行慢开始算法。
执行快恢复算法时，改变滑动窗口的值，然后开始执行拥塞避免算法，使得拥塞窗口缓慢性增大。

三次握手

TCP第三次握手失败 （不会重传ack报文）

当失败时服务器并不会重传ack报文，而是直接发送RTS报文段，进入CLOSED状态。这样做的目的是为了防止SYN洪泛攻击。

那么如果 第三次握手中的ACK包丢失的情况下，Client 向 server端发送数据，Server端将以 RST包响应，方能感知到Server的错误。

syn洪泛攻击：当第三次握手没有发送确认信息时，等待一段时间后，主机就会断开之前的半开连接并回收资源，这为dos攻击埋下隐患，当主动方主动发送大量的syn数据包，但并不做出第三次握手响应，server就会为这些syn包分配资源（但并未使用），就会使server占用大量内存，使server连接环境耗尽，这就是syn洪泛攻击

优化三次握手

• 客户端的优化
  当客户端发起 SYN 包时，可以通过 tcp_syn_retries 控制其重传的次数。
• 服务端的优化

1. 当服务端 SYN 半连接队列溢出后，会导致后续连接被丢弃。（调整 SYN 半连接队列的大小）
2. 如果遭受 SYN 攻击，，应把 tcp_syncookies 参数设置为 1，表示仅在 SYN 队列满后开启 syncookie 功能，可以保证正常的连接成功建立。
3. 服务端收到客户端返回的 ACK，会把连接移入 accpet 队列，等待进行调用 accpet() 函数取出连接。如果 accept 队列溢出，系统默认丢弃 ACK，如果可以把 tcp_abort_on_overflow 设置为 1 ，表示用 RST 通知客户端连接建立失败。
4. TCP Fast Open 功能可以绕过三次握手，使得 HTTP 请求减少了 1 个 RTT 的时间，Linux 下可以通过 tcp_fastopen 开启该功能，同时必须保证服务端和客户端同时支持。（在客户端首次建立连接时的过程，SYN 报文包含 Fast Open 选项正常三次握手。客户端再次向服务器建立连接，如果服务器接受了 SYN 报文中的「数据」，服务器可在握手完成之前发送「数据」，这就减少了握手带来的 1 个 RTT 的时间消耗）
   

如何防御 SYN 攻击？

• 增大半连接队列；
• 开启 tcp_syncookies 功能
• 减少 SYN+ACK 重传次数

优化四次挥手

主动关闭连接的，才有 TIME_WAIT 状态。