网络传输协议
OSI 七层模型和 TCP/IP五层模型
除了 应用层都属于 内核
HTTP协议 <应用层>
socket
exec 8<> /dev/tcp/www.baidu.com/80 输入输出重定向 建立和百度的socket连接
exec 如果后面给出命令，则 将当前shell进程（shell进程本来是个死循环）替换为给出命令 ，命令执行完后，进程退出
如果后面跟的不是命令（输入输出重定向不属于命令），则shell不会被替换，当前进程也不会退出，但是输入输出重定向会执行
cd /proc/$$/fd 到目录可以查看
echo -e “GET / HTTP/1.0\n” 1>& 8 输入 到8 相当于通过socket传输给百度 (输入给文件是> 输入给流是 >&)
cat 0 <& 8 将8的输出 重定向到 标准输入 然后 cat
- socket 是双向的<俩边都会存在>
- socket 是套接字 ip:port + ip:port 有一方不一样则不一样。所以一个端口可以被多个IP或者一个IP的多个端口连接
- port 最多是65535个
TCP协议<传输控制层>
面向连接的可靠的传输协议(必须答出来)
面向连接----三次握手
可靠的—任何数据在传递过程中，都有一个确认的过程，只有收到确认，才会进行后续传递，如果超过最长等待时间(2MSL)则重新发送
三次握手
- C–syn—>S
- S–syn+ack–>C
- C–ack–>S
一旦三次握手之后建立了连接，双方系统内核为对方开辟相应的资源提供服务(开闭提供服务的资源相当于连接)
四次挥手 （重点）
- C–fin–>S
- S–ack–>C
- S–fin–>C
- C–sck–>S
- CLOSE_WAIT状态 被动方将需要继续传输给主动方的数据传输给主动方，传输结束后，被动方发送FIN请求
- FIN_WAIT_2时 处于半连接状态，主动方不再传输数据给被动方
- TIME_WAIT在发送完ACK后，依然需要等待2MSL
为什么需要TIME_WAIT
如果没有TIME_WAIT而是主动方发送完ACK后直接关闭，存在ACK传输失败的情况，此时，被动方接收不到ACK，会持续发送FIN请求，但主动方关闭不能接收。因此需要等待2MSL
为什么TIME_WAIT时间是2MSL
MSL是TCP报文的最大生命周期,超过2MSL可以保证2个方向上的报文传输均已生效消失。
UDP协议<传输控制层>
- 用户数据报协议
- 无连接
- 支持一对一，一对多，多对一
- 不可靠传输服务
- UDP是面向报文的 TCP是面向字节流的
- UDP向上提供无连接不可靠服务，如果发生丢包，不会关心
- UDP适用于实时应用（IP电话，视频会议等）
- UDP首部简单 TCP首部较长(因为需要可靠传输)
IP协议<网路层>
路由寻址
- 下一跳 内存小 速度快 不可靠(其实比较可靠)
路由表主要字段
- Destination： 目的地址，可以是主机地址、网络地址，常用的是网络地址
- Gateway： 网关地址，所有未知地址都会找网关，有网关统一转发，只有边缘网络才会配置网关，并且直连网络不需要配置网关
- Genmask：目的地址的子网掩码
- Iface： 接口，去往目的地址的网络路径的出口（也就是从那个出口可以去往目的地址）
步骤
- 将目标IP与路由表中的子网掩码做&运算，如果和下一跳目标地址相同，则将目标IP以数据包的形式传给下一跳。
- 如果在同一个局域网，则不需要走下一跳(在路由表中表现为下一跳目标地址为0.0.0.0)，网卡走交换机。
- 其实 IP层传输的IP一直没变，但链路层传输的Mac地址是下一跳的Mac地址，会形成一个链表，一直发生变化。
ARP协议<链路层>
- 是通过IP地址获取下一跳的Mac地址然后传输
- 如果没有存下一跳的Mac地址，会在局域网中发送个请求，请求获取下一跳IP的Mac地址。然后请求得到相应，得到Mac地址，然后回调到传输控制层，然后再进行包装并传输出去