TCP三次握手四次挥手

TCP头部报文

  • source port/destination port
    源/目标端口号
  • sequence number
    字节流中每个字节的编号,用于TCP通信过程中确定数据通信的有序性
  • acknowledgement number
    确认序列号,N表示之前N-1为止的所有数据都已经确认收到
  • ISN(Initial Sequence Number)
  • TCP FLAG
    • ACK
      ACK=0表示接收端未应答,ACK=1表示接收端已经接收到数据
    • SYN
      同步序列号,常用于确认端口存在,TCP握手发送的第一个数据包,SYN=1表示接收端已经准备好了
    • FIN
      数据末尾,常用于端口扫描,通知接收端已经到数据末尾,可以关闭连接了

三次握手过程

三次握手过程其实是指建立一个TCP连接时,需要客户端和服务器总共发送3个包
三次握手主要就是为了确认双方的接收能力和发送能力是否正常,指定自己的初始化序列号为后面的可靠性传输做准备。
实质上就是连接服务器指定端口,建立TCP连接,同步双方序列号和确认号,交换TCP窗口大小信息

  • 初始状态
    客户端处于closed状态,服务器端处于listen状态

  • 第一次握手
    客户端 发送 SYN=1(客户端SYN) sequence num=x(客户端ISN)
    状态 SYN_Send

  • 第二次握手
    服务端 发送 SYN=1(服务端SYN) sequence num=y(服务端ISN) ACK=1 acknowledgement number=x+1
    状态 SYN_RCVD

  • 第三次握手
    客户端 发送 ACK=1 sequence num=x+1 acknowledgement number=y+1
    状态 ESTABLISHED

相关问题

  • 为什么是三次握手?
    只有三次握手才能确认双方的发送和接收能力

  • 两次握手行不行?
    不行,比如客户端发送连接请求,但是由于网络原因过了一会儿这个请求才到达服务端,但是客户端又发送了一次连接请求,并且连接成功,传输完数据后关闭了连接,但是这时之前的第一次请求到达了服务端,如果是两次握手,那么服务端会认为此时建立了连接,客户端会一直忽略服务端发送的确认信息,造成服务端一直在等待客户端发送数据,浪费资源

  • 什么是半连接队列?
    服务端第一次接收到客户端的SYN之后,会处于SYN_RCVD状态,此时连接并没有建立,服务端会把处于这种状态下的请求连接放在一个队列中,我把这种队列称为半连接队列,服务端同时还维护一个全连接队列。服务端发送完SYN-ACK包后,如果收不到客户端的确认消息,会每隔一段时间发送一次SYN-ACK包,当发送次数超过规定次数后,会将该客户端踢出半连接队列。

  • ISN
    三次握手的其中一个重要功能是客户端和服务端交换 ISN(Initial Sequence Number),以便让对方知道接下来接收数据的时候如何按序列号组装数据。如果 ISN 是固定的,攻击者很容易猜出后续的确认号,因此 ISN 是动态生成的。

  • 三次握手时可以携带数据么?
    第一次第二次不可以携带数据,防止被恶意攻击,每次都在第一次握手放入大量数据,服务端会浪费很多资源和时间来接收这些无用的报文。

  • SYN攻击是什么?
    服务端的资源分配是第二次握手时分配的,客户端的资源分配是第三次握手时分配的。客户端短时间内通过不同的伪造IP,不断向服务端发送SYN包,服务端会和一堆不存在的IP进行第二次握手确认,同时会将这些伪造的客户端加入半连接队列,导致正常的客户端请求被挤出队列
    防御方法:缩短超时时间、增加半连接队列长度、过滤网关防护、SYN cookies技术

四次挥手过程

TCP的半关闭状态,指的是TCP提供了连接的一端在结束发送后还能接收来自对方数据的能力。

  • 初识状态
    双方都处于ESTABLISHED状态
  • 第一次挥手
    客户端 发送 FIN=1 sequence num=u(客户端seq)
    状态 FIN_WAIT1
  • 第二次挥手
    服务端 发送 ACK=1 sequence num=v(服务端seq) acknowledgement number=u+1
    状态 CLOSE_WAIT
  • 第三次挥手
    服务端 发送 FIN=1 ACK=1 sequence num=w(服务端seq) acknowledgement number=u+1
    状态 LAST_ACK
  • 第四次挥手
    客户端 发送 ACK=1 sequence num=u+1(客户端seq) acknowledgement number=w+1
    状态 CLOSED

相关问题

  • 为什么是四次挥手?
    一方发送FIN=1,那么另外一方需要先ACK=1确认收到最后一条消息,然后再另外发送一条FIN=1表示这是自己的最后一条信息。
  • 2MSL等待时间
    MSL(Maximum Segment Lifetime),报文段被丢弃前在网络内的最长时间,在挥手过程中最后一次发送ACK=1包后等待2MSL的时间内不能关闭,同时该连接在这2MSL时间内不能再次使用。
  • 等待2MSL的意义
    • 保证客户端发送的最后一个ACK=1包能够到达服务端
    • 防止已经失效的连接的请求包出现在别的连接中
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,293评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,604评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,958评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,729评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,719评论 5 366
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,630评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,000评论 3 397
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,665评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,909评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,646评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,726评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,400评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,986评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,959评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,197评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,996评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,481评论 2 342

推荐阅读更多精彩内容