专栏首页FluentStudy每日一题:三次握手与四次挥手上篇

每日一题:三次握手与四次挥手上篇

点击上方蓝色字体,关注我们

今天来聊聊面试频率特别高的一个题目:TCP 协议中的三次握手与四次挥手。涉及到的知识点有:

1、TCP、UDP 协议的区别 2、TCP 头部结构 3、三次握手与四次挥手过程详解 4、什么是 TIME_WATI 状态

由于涉及东西比较多,将分两篇介绍,本篇算是背景知识。

本文略长,需要有点耐心

一、TCP、UDP 协议的区别

在介绍这两者的区别之前,我们要需要了解一个概念:TCP/IP 协议族。定义如下:

目前 Internet(因特网)使用的主流协议族是 TCP/IP 协议族,它是一个分层、多协议的通信体系 《Linux高性能编程》

提取关键词:分层、多协议和通信。也就是说,它有多个层次,每个层次有不同的协议,这些层次之间通过协议相互协作,最终达到网络通信的目的。

说到分层,应该不会很陌生,TCP/IP 协议族是一个四层协议系统,自底而上分别是:数据链接层、网络层、传输层、应用层。我们这里要说到的 TCP 和 UDP 协议属于传输层。(各层的作用及相关协议这里暂时先不做介绍)

下面我们回到标题:TCP、UDP 协议的区别,总结起来这个问题的答案要点如下:

1、首页它们俩都是传输层的协议,而所谓“传输层”,它是为两台主机提供端到端的通信,即从 A <-> B 。

2、TCP 协议可靠,UDP 协议不可靠。可靠即指数据由 A 发送到 B,是否能确保数据真的有送达到 B。TCP 协议使用 超时重传、数据确认等方式来确保数据包被正确地发送至目的端,而 UDP 协议无法保证数据从发送端正确传送到目的端,如果数据在传输过程中丢失、或者目的端通过数据检验发现数据错误,则 UDP 协议只是简单地通知应用程序发送失败,对于 TCP 协议拥有的超时重传、数据确认等需要应用程序自己来处理这些逻辑。

3、TCP 是面向连接的,UDP 是无连接的。这也比较好理解,因为 TCP 连接才需要“三次握手,四次挥手”。

4、TCP 服务是基于流的,而 UDP 是基于数据报的,基于流的数据没有边界(长度)限制,而基于数据报的服务,每个 UDP 数据报都有一个长度,接收端必须以该长度为最小单位将其所有内容一次性读出。

5、当发送方多次执行写操作时,TCP 模块会先将这些数据放入 TCP 发送缓冲区中,当 TCP 模块真正开始发送数据时,发送缓冲区中这些等待发送的数据可能被封装成一个或多个 TCP 报文段发出,因此,TCP 模块发出的 TCP 报文段的个数与应用程序执行的写操作次数是没有固定数量关系的。同样,当接收端收到一个或多个 TCP 报文段后,TCP 模块将这些数据按照序号(序号说明见下面 的 TCP 头部结构)依次放入 TCP 接收缓冲区中,并通知应用程序读取数据。接收端可选择一次或者分多次将数据从缓冲区中读出(这取决于用户指定的应用程序读缓冲区的大小)。因此,接收端读取数据的次数与发送端发出多少个报文段个数也没有固定的数量关系。总结来说,即对于 TCP 连接,发送端执行的写操作次数与接收端执行的读操作次数之间没有任何数据关系,这也是基于流服务的特点。而对于 UDP 服务,发送端每执行一次写操作,就会将其封装成一个 UDP 数据报并发送之,同时接收端必须根据发送的进行读,否则就会丢包。因此,对于 UDP 连接,发送端写的次数据与读的次数是一致的,这也是基于数据报的服务的特点

6、TCP 的连接是一对一的,所以如果是基于广播或者多播的的应用程序不能使用 TCP,而 UDP 则非常适合广播和多播。

总结一句定义:

TCP 协议(Transmission Control Protocal,传输控制协议)为应用层提供可靠的、面向连接的、基于流的服务。而 UDP 协议(User Datagram Protocal,用户数据报协议)则与 TCP 协议完全相反,它为应用层提供不可靠、无连接和基于数据报的服务

二、TCP 头部结构

TCP 报文结构分为头部部分和数据部分,为什么需要了解 TCP 头部结构,因为在后面“三次握手与四次挥手”里会用到头部结构里的标志位。简单了解下对理解后面的过程有一定的好处。

下面一一说明每个的作用: 16位源端口号与目的端口号,这个比较好理解,就不过多解释。

32位序号:在建立连接(或者关闭)的过程,这个序号是用来做占位,当 A 发送连接请求到 B,这个时候会带上一个序号(随机值,称为 ISN),而 B 确认连接后,会把这个序号 +1 返回,同时带上自己的充号。当建立连接后,该序号为生成的随机值 ISN 加上该段报文段所携带的数据的第一个字节在整个字节流中的偏移量。比如,某个 TCP 报文段发送的数据是字节流中的第 100 ~ 200 字节,那该序号为 ISN + 100。所以总结起来说明建立连接(或者关闭)时,序号的作用是为了占位,而连接后,是为了标记当前数据流的第一个字节。

4位头部长度:标识 TCP 头部有多少个 32 bit 字,因为是 4位,即 TCP 头部最大能表示 15,即最长是 60 字节。即它是用来记录头部的最大长度。

6位标志位,包括: URG 标志:表示紧急指针是否有效。 ACK 标志:确认标志。通常称携带 ACK 标志的 TCP 报文段为确认报文段。 PSH 标志:提示接收端应该程序应该立即从 TCP 接收缓冲区中读走数据,为接收后续数据腾出空间(如果不读走,数据就会一直在缓冲区内)。 RST 标志:表示要求对方重新建立连接。通常称携带 RST 标志的 TCP 报文段为复位报文段SYN 标志:表示请求建立一个连接。通常称携带 SYN 标志的 TCP 报文段称为同步报文段FIN 标志:关闭标志,通常称携带 FIN 标志的 TCP 报文段为结束报文段这些标志位说明了当前请求的目的,即要干什么。

16 位窗口大小:表示当前 TCP 接收缓冲区还能容纳多少字节的数据,这样发送方就可以控制发送数据的速度,它是 TCP 流量控制的一个手段。

16 位校验和:验证数据是否损坏,通过 CRC 算法检验。这个校验不仅包括 TCP 头部,也包括数据部分。

16 位紧急指针:正的偏移量,它和序号字段的值相加表示最后一个紧急数据的下一字节的序号。TCP 的紧急指针是发送端向接收端发送紧急数据的方法。

TCP 头部选项:可变长的可选信息,这部分最多包含 40 字节,因为 TCP 头部最长是 60 字节,所以固定部分占 20 字节。这里不做详细介绍,可以参考《Linux高性能编程》3.2.2

你点的每个赞,我都认真当成了喜欢

本文分享自微信公众号 - FluentStudy(gh_30ef659095e0),作者:Demon5203

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-06-27

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 数据库小知识:OLTP 与 OLAP

    OLTP(OnLine Transacion Processing),是传统关系型数据库的主要应用,主要面向基本的、日常的事务处理,例如银行交易等。它是面向交易...

    用户7685359
  • 进程线程概念剖析-基础篇(一)

    上文我们操作系统的基础概念,今天我们来深入剖析下进程、线程的概念。本小节为进程线程基础概念篇(一),主要介绍什么是进程、线程,以及为什么引入进程和线程。

    用户7685359
  • 每日一题:协程相关

    答案要点: a、进程是资源分配,每个进程拥有独立的资源空间,因为进程不共享资源,所以就涉及到进程间通信的方式,常见的方式有:消息队列、管道、信号量、socket...

    用户7685359
  • 哈哈哈,求人办事,切勿 UDP 方式啊,还是 TCP 靠谱呀 [允悲][允悲][允悲]

    1、TCP面向连接(如打电话要先拨号建立连接);UDP是无连接的,即发送数据之前不需要建立连接

    良月柒
  • TCP 是什么?面试时必须知道吗?

    你学习英语时会只背单词不学语法吗?显然不可能,那 TCP 也是一样的,作为计算机网络非常重要的内容,规范了网络传输过程的状态,格式等。

    CSDN技术头条
  • 端口的常用端口

    端口号---具有网络功能的应用软件的标识号。注意,端口号是不固定的,即可以由用户手工可以分配(当然,一般在软件编写时就已经定义)。当然,有很多应用软件有公认的默...

    98k
  • Linux-Python-Scapy的T

    从下到上FIN—SYN—RST—PSH—ACK—URG 1 2 4 8 16 32

    py3study
  • 总结---6

          1.OSI参考模型有多少层?分别是哪几层?(不建议死记硬背,可以看看我在系列文章第一篇里的描述,效果比较好,不会因为紧张而答不出来)        ...

    猿人谷
  • TCP:一个悲伤的故事

    通过本文相信读者能更深刻地理解 TCP 协议,它是个面向连接的可靠传输协议,提供了复杂的拥塞控制与流量控制的功能。当然 TCP 协议博大精深,文中只是介绍了一些...

    kunge
  • TCP 是什么?面试时必须知道吗?

    你学习英语时会只背单词不学语法吗?显然不可能,那 TCP 也是一样的,作为计算机网络非常重要的内容,规范了网络传输过程的状态,格式等。

    用户1737318

扫码关注云+社区

领取腾讯云代金券