基础网络TCP三次握手/四次挥手/DNS协议/ARP协议)

TCP协议/UDP协议

TCP传输控制协议面向连接网络协议 安全可靠
UDP用户报文协议 无连接网络协议 传输效率高 但不安全
TCP协议传输会先判断是否在一个局域网内 没有发现便会经过互联网
TCP协议报文结构
源端口 目标端口 每个占用16个BIt tcp协议端口范围是0-65535 计算方法是2的N次方
序列号 对每一个数据包进行编号方便资源管理确定数据完整性
确认号 告知下一次传输包编号
控制位 数据传输控制管理

报文结构.jpg

报文结构.png

传输中最小默认值为1500字节 比1500字节大的都会被分割
名词:
ACK 确认控制字符 0=无效 1=生效
FIN 断开连接字符 0=无效 1=有效
SYN 请求建立连接 0=无效 1=有效

三次握手

三次握手.jpg

第一次握手:
客户端向服务器发出请求报文,这时报文首部控制位的同部位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状态

  • 首先两个人约定协议
  1. 感觉网络情况不对的时候,任何一方都可以发起询问
  2. 任何情况下,若发起询问后5秒还没收到回复,则认为网络不通
  3. 网络不通的情况下等1min路由器之后再发起询问
  • 对于我而言,发起 “1+1等于几”的询问后
  1. 若5s内没有收到回复,则认为网络不通
  2. 若收到回复,则我确认①我能听到她的消息 ②她能听到我的消息,然后回复她的问题的答案
  • 对于她而言,当感觉网络情况不对的时候
  1. 若没有收到我的询问,则她发起询问
  2. 若收到“1+1等于几”,则她确认 ①她可以听到我的消息,然后回复我的问题的答案和她的问题“2,2+2等于几”
  3. 若5s内没有收到我的回复“4”,则她确认 ②我听不见她的消息
  4. 若5s内收到了我的回复“4”,则她确认 ②我可以听见她的消息
    这样,如果上面的对话得以完成,就证明双方都可以确认自己可以听到对方的声音,对方也可以听到自己的声音!

四次挥手

所谓四次挥手(Four-Way Wavehand)即终止TCP连接,就是指断开一个TCP连接时,需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中,这一过程由客户端或服务端任一方执行close来触发

四次挥手.jpg

第一次握手
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种状态

1350996969_2313.jpg

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 可用状态了。

  • 客户端独有:
  1. SYN_SENT (等待接收连接申请回复状态)
  2. FIN_WAIT 1 (等待远程连接中断请求状态1)
  3. FIN_WAIT 2 (等待远程连接中断请求状态 2)
  4. CLOSING (等待远程TCP对连接中断的确认状态)
  5. TIME_WAIT(等待足够的时间以确保远程TCP接收到连接中断确认信息)
  • 服务端独有
  1. LISTEN (侦听来自远方TCP端口的连接申请)
  2. SYN_RCVD (等待客户端回复连接申请状态)
  3. CLOSE_WAIT (等待TCP远程连接中断的确认)
  4. LAST_ACK(等待原来发向远程TCP的中断连接确认)
  • 共有
  1. CLOSED (关闭 没有任何连接状态)
  2. ESTABLISHED (通讯 连接成功状态)

网络重要协议

  • DNS协议原理 , 建立IP地址和域名对应关系
    作用 将域名信息转换为IP地址
    DNS解析过程
  1. 本地查询解析记录
    (1) 查看本地DNS缓存,可以利用ipconfig 如果本地有记录便会直接访问
    (2) 本机手动配置DNS解析 电脑配置文件存放地点C:\Windows\System32\drivers\etc\hosts
    当本地查找不到时会到网上LDNS服务器上进行查找
  2. 递归查询
    当本地查找不到 会在网上LDNS服务器(域名服务器)上进行查找DNS解析 找到对应的DNS解析发送到主机上以获取地址
    常见DNS服务器有223.5.5.5 / 2223.6.6.6
  3. 迭代查询
    LDNS也没找到对应地址时便会向根域名发送请求
    根域名服务器会提供顶级服务器的信息,顶级服务器会发送二级服务器信息直到对应的域名服务器 然后返回信息
    一个网址的全称写法www.baidu.con.
    .代表根域名服务器 用于提供顶级域名服务器信息
    .com代表顶级服务器 提供二级域名服务器信息
    .baidu代表二级服务器 提供IP和域名对应关系
    www代表不同的网站
    得到信息后就会建立TCP三次握手 开始访问网址传输数据
    dig 网址 +trace 查看DNS解析过程
  • ARP协议
    ARP协议 用于建立IP和MAC地址对应关系(一般局域网常用)
  1. 一台主机向另一台主机发送信息时, 会发送一个Request请求MAC地址
    另一台主机收到后会回复Reply MAC地址 两台主机的ARP协议会记录MAC地址 接着开始会话

  2. 在交换机环境中(多台机器) 一台向另一台服务器发送信息时 会发送一个Request包 这时Request内信息为目标IP 源IP 源MAC FF 因为不知道目标MAC 所有会广播给所有用户 进行解析
    当目标IP地址主机收到后回复Reply 自己的MAC地址这个过程就是ARP询问 / 回复

  3. ARP会在主机中生成一个ARP表 (IP地址对应的MAC地址表)
    每次通讯都会记录IP对应的MAC地址 在多次广播后ARP中就存储了完整的对应表 之后发送信息就不用再广播 节省资源

ARP原理说明:

  1. 构建ARP请求和回复信息 从而获得MAC地址
  2. 构建ARP表 表内有IP和MAC对应关系信息
  3. 构建完成后减少广播发送次数 减少资源浪费
  • ARP缓存表有状态
  1. 动态 动态更新或添加ARP表信息 会定期更新
    主机插入网线后交换机会立刻获取MAC地址组成 交换机的MAC表,主机会随时更新自己的ARP表
    应用场景 : 办公室常用
  2. 静态 手工配置ARP表信息 永久保留
    主机配置静态表 局域网内所有的主机都有配置静态表 否则不生效
    应用场景: 数据中心 / IDC机房
  • 查看路由表信息
  1. route -n
  2. netstat -rn
  3. ip route show
    三个命令都是查看路由表规则信息
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,456评论 5 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,370评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,337评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,583评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,596评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,572评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,936评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,595评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,850评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,601评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,685评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,371评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,951评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,934评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,167评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,636评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,411评论 2 342