TCP协议/UDP协议
TCP传输控制协议面向连接网络协议 安全可靠
UDP用户报文协议 无连接网络协议 传输效率高 但不安全
TCP协议传输会先判断是否在一个局域网内 没有发现便会经过互联网
TCP协议报文结构
源端口 目标端口 每个占用16个BIt tcp协议端口范围是0-65535 计算方法是2的N次方
序列号 对每一个数据包进行编号方便资源管理确定数据完整性
确认号 告知下一次传输包编号
控制位 数据传输控制管理
传输中最小默认值为1500字节 比1500字节大的都会被分割
名词:
ACK 确认控制字符 0=无效 1=生效
FIN 断开连接字符 0=无效 1=有效
SYN 请求建立连接 0=无效 1=有效
三次握手
第一次握手:
客户端向服务器发出请求报文,这时报文首部控制位的同部位SYN=1(建立连接) 同时随机生成初始序列号seq=n 此时客户端进程进入SYN-SENT(同步已发送状态)
第二次握手:
TCP服务端收到请求报文后同意则发出确认报文, 确认报文: ACK=1 SYN=1 确认号为 ack=n+1 同时自己也要生成一个初始化序列号seq=m 此时服务器进入了SYN-RCUD(同步接收状态)
第三次握手:
TCP客户端收到确认后向服务端发送一个确认报文 (ACK=1 seq=n+1 ack=m+1) 此时TCP建立连接 客户端进入ESTABLISHED状态
- 首先两个人约定协议
- 感觉网络情况不对的时候,任何一方都可以发起询问
- 任何情况下,若发起询问后5秒还没收到回复,则认为网络不通
- 网络不通的情况下等1min路由器之后再发起询问
- 对于我而言,发起 “1+1等于几”的询问后
- 若5s内没有收到回复,则认为网络不通
- 若收到回复,则我确认①我能听到她的消息 ②她能听到我的消息,然后回复她的问题的答案
- 对于她而言,当感觉网络情况不对的时候
- 若没有收到我的询问,则她发起询问
- 若收到“1+1等于几”,则她确认 ①她可以听到我的消息,然后回复我的问题的答案和她的问题“2,2+2等于几”
- 若5s内没有收到我的回复“4”,则她确认 ②我听不见她的消息
- 若5s内收到了我的回复“4”,则她确认 ②我可以听见她的消息
这样,如果上面的对话得以完成,就证明双方都可以确认自己可以听到对方的声音,对方也可以听到自己的声音!
四次挥手
所谓四次挥手(Four-Way Wavehand)即终止TCP连接,就是指断开一个TCP连接时,需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中,这一过程由客户端或服务端任一方执行close来触发
第一次握手
TCP发送一个FIN(结束),用来关闭客户到服务端的连接。
客户端进程发出连接释放报文,并且停止发送数据。释放数据报文首部,FIN=1,其序列号为seq=u(等于前面已经传送过来的数据的最后一个字节的序号加1),
此时,客户端进入FIN-WAIT-1(终止等待1)状态。
第二次握手
服务端收到这个FIN,他发回一个ACK(确认),确认收到序号为收到序号+1,和SYN一样,一个FIN将占用一个序号。
服务器收到连接释放报文,发出确认报文,ACK=1,ack=u+1,并且带上自己的序列号seq=v,此时,服务端就进入了CLOSE-WAIT(关闭等待)状态。TCP服务器
通知高层的应用进程,客户端向服务器的方向就释放了,这时候处于半关闭状态,即客户端已经没有数据要发送了,但是服务器若发送数据,客户端依然要接受。这个
状态还要持续一段时间,也就是整个CLOSE-WAIT状态持续的时间。
客户端收到服务器的确认请求后,此时,客户端就进入FIN-WAIT-2(终止等待2)状态,等待服务器发送连接释放报文(在这之前还需要接受服务器发送的最后的数据)。
第三次握手
服务端发送一个FIN(结束)到客户端,服务端关闭客户端的连接。
服务器将最后的数据发送完毕后,就向客户端发送连接释放报文,FIN=1,ack=u+1,由于在半关闭状态,服务器很可能又发送了一些数据,假定此时的序列号为seq=w,
此时,服务器就进入了LAST-ACK(最后确认)状态,等待客户端的确认。
第四次握手
客户端发送ACK(确认)报文确认,并将确认的序号+1,这样关闭完成。
客户端收到服务器的连接释放报文后,必须发出确认,ACK=1,ack=w+1,而自己的序列号是seq=u+1,此时,客户端就进入了TIME-WAIT(时间等待)状态。注意此时
TCP连接还没有释放,必须经过2∗∗MSL(最长报文段寿命)的时间后,当客户端撤销相应的TCB后,才进入CLOSED状态。
服务器只要收到了客户端发出的确认,立即进入CLOSED状态。同样,撤销TCB后,就结束了这次的TCP连接。可以看到,服务器结束TCP连接的时间要比客户端早一些。
什么是2MSL
MSL是Maximum Segment Lifetime英文的缩写,中文可以译为“报文最大生存时间”,他是任何报文在网络上存在的最长时间,超过这个时间报文将被丢弃。因为tcp报文(segment)是ip数据报(datagram)的数据部分,具体称谓请参见《数据在网络各层中的称呼》一文,而ip头中有一个TTL域,TTL是time to live的缩写,中文可以译为“生存时间”,这个生存时间是由源主机设置初始值但不是存的具体时间,而是存储了一个ip数据报可以经过的最大路由数,每经过一个处理他的路由器此值就减1,当此值为0则数据报将被丢弃,同时发送ICMP报文通知源主机。RFC 793中规定MSL为2分钟,实际应用中常用的是30秒,1分钟和2分钟等。
2MSL即两倍的MSL,TCP的TIME_WAIT状态也称为2MSL等待状态,当TCP的一端发起主动关闭,在发出最后一个ACK包后,即第3次握手完成后发送了第四次握手的ACK包后就进入了TIME_WAIT状态,必须在此状态上停留两倍的MSL时间,等待2MSL时间主要目的是怕最后一个ACK包对方没收到,那么对方在超时后将重发第三次握手的FIN包,主动关闭端接到重发的FIN包后可以再发一个ACK应答包。在TIME_WAIT状态时两端的端口不能使用,要等到2MSL时间结束才可继续使用。当连接处于2MSL等待阶段时任何迟到的报文段都将被丢弃。不过在实际应用中可以通过设置SO_REUSEADDR选项达到不必等待2MSL时间结束再使用此端口。
TTL与MSL是有关系的但不是简单的相等的关系,MSL要大于等于TTL。
-
思考:那么为什么是4次挥手呢?
为了确保数据能够完成传输。
关闭连接时,当收到对方的FIN报文通知时,它仅仅表示对方没有数据发送给你了;但未必你所有的数据都全部发送给对方了,所以你可以未必会马上会关闭SOCKET,也
即你可能还需要发送一些数据给对方之后,再发送FIN报文给对方来表示你同意现在可以关闭连接了,所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。
可能有人会有疑问,tcp我握手的时候为何ACK(确认)和SYN(建立连接)是一起发送。挥手的时候为什么是分开的时候发送呢.
因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到
FIN报文时,很可能并不会立即关闭 SOCKET,所以只能先回复一个ACK报文,告诉Client端,"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了,我才能
发送FIN报文,因此不能一起发送。故需要四步握手
关于三次握手与四次挥手通常都会有典型的面试题
(1)三次握手是什么或者流程?四次握手呢?
(2)为什么建立连接是三次握手,而关闭连接却是四次挥手呢?
TCP 11种状态
CLOSED:初始状态,表示TCP连接是“关闭着的”或“未打开的”。
LISTEN :表示服务器端的某个SOCKET处于监听状态,可以接受客户端的连接。
SYN_RCVD :表示服务器接收到了来自客户端请求连接的SYN报文。在正常情况下,这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态,很短暂,基本上用netstat很难看到这种状态,除非故意写一个监测程序,将三次TCP握手过程中最后一个ACK报文不予发送。当TCP连接处于此状态时,再收到客户端的ACK报文,它就会进入到ESTABLISHED 状态。
SYN_SENT :这个状态与SYN_RCVD 状态相呼应,当客户端SOCKET执行connect()进行连接时,它首先发送SYN报文,然后随即进入到SYN_SENT 状态,并等待服务端的发送三次握手中的第2个报文。SYN_SENT 状态表示客户端已发送SYN报文。
ESTABLISHED :表示TCP连接已经成功建立。
FIN_WAIT_1:这个状态得好好解释一下,其实FIN_WAIT_1 和FIN_WAIT_2 两种状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是:FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时,它想主动关闭连接,向对方发送了FIN报文,此时该SOCKET进入到FIN_WAIT_1 状态。而当对方回应ACK报文后,则进入到FIN_WAIT_2 状态。当然在实际的正常情况下,无论对方处于任何种情况下,都应该马上回应ACK报文,所以FIN_WAIT_1 状态一般是比较难见到的,而FIN_WAIT_2 状态有时仍可以用netstat看到。
FIN_WAIT_2 :上面已经解释了这种状态的由来,实际上FIN_WAIT_2状态下的SOCKET表示半连接,即有一方调用close()主动要求关闭连接。注意:FIN_WAIT_2 是没有超时的(不像TIME_WAIT 状态),这种状态下如果对方不关闭(不配合完成4次挥手过程),那这个 FIN_WAIT_2 状态将一直保持到系统重启,越来越多的FIN_WAIT_2 状态会导致内核crash。
TIME_WAIT :表示收到了对方的FIN报文,并发送出了ACK报文。 TIME_WAIT状态下的TCP连接会等待2MSL(Max Segment Lifetime,最大分段生存期,指一个TCP报文在Internet上的最长生存时间。每个具体的TCP协议实现都必须选择一个确定的MSL值,RFC 1122建议是2分钟,但BSD传统实现采用了30秒,Linux可以cat /proc/sys/net/ipv4/tcp_fin_timeout看到本机的这个值),然后即可回到CLOSED* 可用状态了。如果FIN_WAIT_1状态下,收到了对方同时带FIN标志和ACK标志的报文时,可以直接进入到TIME_WAIT状态,而无须经过FIN_WAIT_2状态。(这种情况应该就是四次挥手变成三次挥手的那种情况)
CLOSING :这种状态在实际情况中应该很少见,属于一种比较罕见的例外状态。正常情况下,当一方发送FIN报文后,按理来说是应该先收到(或同时收到)对方的ACK报文,再收到对方的FIN报文。但是CLOSING 状态表示一方发送FIN报文后,并没有收到对方的ACK报文,反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢?那就是当双方几乎在同时close()一个SOCKET的话,就出现了双方同时发送FIN报文的情况,这是就会出现CLOSING 状态,表示双方都正在关闭SOCKET连接。
CLOSE_WAIT :表示正在等待关闭。怎么理解呢?当对方close()一个SOCKET后发送FIN报文给自己,你的系统毫无疑问地将会回应一个ACK报文给对方,此时TCP连接则进入到CLOSE_WAIT状态。接下来呢,你需要检查自己是否还有数据要发送给对方,如果没有的话,那你也就可以close()这个SOCKET并发送FIN报文给对方,即关闭自己到对方这个方向的连接。有数据的话则看程序的策略,继续发送或丢弃。简单地说,当你处于CLOSE_WAIT 状态下,需要完成的事情是等待你去关闭连接。
LAST_ACK :当被动关闭的一方在发送FIN报文后,等待对方的ACK报文的时候,就处于LAST_ACK 状态。当收到对方的ACK报文后,也就可以进入到CLOSED 可用状态了。
- 客户端独有:
- SYN_SENT (等待接收连接申请回复状态)
- FIN_WAIT 1 (等待远程连接中断请求状态1)
- FIN_WAIT 2 (等待远程连接中断请求状态 2)
- CLOSING (等待远程TCP对连接中断的确认状态)
- TIME_WAIT(等待足够的时间以确保远程TCP接收到连接中断确认信息)
- 服务端独有
- LISTEN (侦听来自远方TCP端口的连接申请)
- SYN_RCVD (等待客户端回复连接申请状态)
- CLOSE_WAIT (等待TCP远程连接中断的确认)
- LAST_ACK(等待原来发向远程TCP的中断连接确认)
- 共有
- CLOSED (关闭 没有任何连接状态)
- ESTABLISHED (通讯 连接成功状态)
网络重要协议
- DNS协议原理 , 建立IP地址和域名对应关系
作用 将域名信息转换为IP地址
DNS解析过程
- 本地查询解析记录
(1) 查看本地DNS缓存,可以利用ipconfig
如果本地有记录便会直接访问
(2) 本机手动配置DNS解析 电脑配置文件存放地点C:\Windows\System32\drivers\etc\hosts
当本地查找不到时会到网上LDNS服务器上进行查找 - 递归查询
当本地查找不到 会在网上LDNS服务器(域名服务器)上进行查找DNS解析 找到对应的DNS解析发送到主机上以获取地址
常见DNS服务器有223.5.5.5 / 2223.6.6.6 - 迭代查询
LDNS也没找到对应地址时便会向根域名发送请求
根域名服务器会提供顶级服务器的信息,顶级服务器会发送二级服务器信息直到对应的域名服务器 然后返回信息
一个网址的全称写法www.baidu.con.
.
代表根域名服务器 用于提供顶级域名服务器信息
.com
代表顶级服务器 提供二级域名服务器信息
.baidu
代表二级服务器 提供IP和域名对应关系
www
代表不同的网站
得到信息后就会建立TCP三次握手 开始访问网址传输数据
dig 网址 +trace
查看DNS解析过程
- ARP协议
ARP协议 用于建立IP和MAC地址对应关系(一般局域网常用)
一台主机向另一台主机发送信息时, 会发送一个
Request
请求MAC地址
另一台主机收到后会回复Reply MAC地址
两台主机的ARP协议会记录MAC地址 接着开始会话在交换机环境中(多台机器) 一台向另一台服务器发送信息时 会发送一个
Request
包 这时Request
内信息为目标IP 源IP 源MAC FF
因为不知道目标MAC 所有会广播给所有用户 进行解析
当目标IP地址主机收到后回复Reply 自己的MAC地址
这个过程就是ARP询问 / 回复ARP会在主机中生成一个ARP表 (IP地址对应的MAC地址表)
每次通讯都会记录IP对应的MAC地址 在多次广播后ARP中就存储了完整的对应表 之后发送信息就不用再广播 节省资源
ARP原理说明:
- 构建ARP请求和回复信息 从而获得MAC地址
- 构建ARP表 表内有IP和MAC对应关系信息
- 构建完成后减少广播发送次数 减少资源浪费
- ARP缓存表有状态
- 动态 动态更新或添加ARP表信息 会定期更新
主机插入网线后交换机会立刻获取MAC地址组成 交换机的MAC表,主机会随时更新自己的ARP表
应用场景 : 办公室常用 - 静态 手工配置ARP表信息 永久保留
主机配置静态表 局域网内所有的主机都有配置静态表 否则不生效
应用场景: 数据中心 / IDC机房
- 查看路由表信息
route -n
netstat -rn
-
ip route show
三个命令都是查看路由表规则信息