网络传输协议
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地址,然后回调到传输控制层,然后再进行包装并传输出去