美文网首页
网络架构系列1--TCP/IP详解

网络架构系列1--TCP/IP详解

作者: 倔脾气的皮皮虾啊 | 来源:发表于2020-01-10 21:04 被阅读0次

不诗意的女程序媛不是好厨师~
转载请注明出处,From李诗雨---https://blog.csdn.net/cjm2484836553/article/details/103930596

网络架构,可以算得上是面试的宠儿了,我也废话不多说,直接上重点。

本节内容思维导图

1.计算机网络分层▲(面试点)

1.1 OSI七层网络模型 和 TCP/IP参考模型

  • 重点1:OSI七层网络模型 和 TCP/IP参考模型 ,它可是面试的敲门砖,所以大概的内容要记住。

(PS:作为贴心小棉袄的我,已经画了个好看的图,方便大家背诵~)

image

关于OSI模型 和 TCP/IP模型,大家可以这么理解。

OSI七层模型 偏向于一种 理想化的,就好比学术界定义的。而TCP/IP四层模型,则是工业界中实际使用的。

  • 重点2: 大家要知道 TCP/IP是一组协议的代名词,它还包括许多协议,组成了TCP/IP协议簇。

    从字面上来看,有人可能会认为 TCP/IP 是指 TCP 和 IP 两种协议。实际生活当中,有时也确实就是指这两种协议。但是在很多情况下,它只是利用 IP 进行通信时所必须用到的协议群的统称。具体来说,IP 或 ICMP、TCP 或 UDP、TELNET 或 FTP、以及 HTTP 等都属于 TCP/IP 协议。

    此外我们还要知道,在TCP/IP协议簇中, IP位于网络层TCP位于传输层HTTP位于应用层

    在这里插入图片描述
    在这里插入图片描述

2.IP地址 和 端口号

这里有2个概念需要我们来解释一下,因为在面试只也有可能会提到。

2.1 IP地址

在这里插入图片描述

为了实现网络中不同终端之间的通信,每个终端必须有一个唯一的表示,它就是IP地址

  • 所以,如果问 两台终端是如何通过网络进行通信的?

    那你要知道答案是 IP地址。

    可不是MAC地址哈,因为mac地址只在局域网有效,不能出局域网。

2.2 端口号➹(暗涉一道面试题)

在这里插入图片描述

我们可以把端口号,理解为门牌号。

通过ip地址,我们可以知道我们要访问的是哪台计算机。但是一台计算机可以同时运行多个程序,我们如何知道要访问哪个应用程序呢?这就要通过端口号了。

端口号用来识别同一台计算机中进行通信的不同应用程序。因此,它也被称为程序地址

在这里插入图片描述

端口号规定为16位,即允许一个IP主机有2的16次方65535个不同的端口。其中:

  • 0~1023:分配给系统的端口号

    我们不可以乱用!!
    常用协议使用的端口:HTTP:80,FTP:21,TELNET:23

  • 1024~49151:登记端口号,主要是让第三方应用使用

    但是必须在IANA(互联网数字分配机构)按照规定手续登记,

  • 49152~65535:短暂端口号,是留给客户进程选择暂时使用,一个进程使用完就可以供其他进程使用。

在Socket使用时,可以用1024~65535的端口号

那这里就隐藏了一个面试题:

既然一个ip主机的端口只有65535个,那为什么可以做到有几百万的socket链接呢?

哈哈,这是因为,我们的通信不是由 端口号 一人决定的呀。我们的通信识别一个通信 是由 5元组 (源IP地址、目标IP地址、源端口号、目标端口 和 协议号)来一起决定的。

在这里插入图片描述

如图:

① 和② 的通信是在两台计算机上进行的。它们的目标端口号相同,都是80。这里可以根据源端口号加以区分。

① 和③ 的目标端口号和源端口号完全相同,但它们各自的源 IP 地址不同。

此外,当 IP 地址和端口号全都一样时,我们还可以通过协议号来区分(TCP 和 UDP)。

3. TCP和UDP

TCP/IP 中有两个具有代表性的传输层协议,分别是 TCP 和 UDP。

3.1 TCP的定义和特点

  • 定义:Transmission Control Protocol,即传输控制协议,是一种传输层通信协议

    基于TCP的应用层协议有FTP、Telnet、SMTP、HTTP、POP3与DNS。

  • 特点:面向连接、面向字节流、全双工通信、可靠

    • 面向连接:指的是要使用TCP传输数据,必须先建立TCP连接,传输完成后释放连接,就像打电话一样必须先拨号建立一条连接,打完后挂机释放连接。
    • 全双工通信:即一旦建立了TCP连接,通信双方可以在任何时候都能发送数据。
    • 可靠的:指的是通过TCP连接传送的数据,无差错,不丢失,不重复,并且按序到达。
    • 面向字节流:流,指的是流入到进程或从进程流出的字符序列。简单来说,虽然有时候要传输的数据流太大,TCP报文长度有限制,不能一次传输完,要把它分为好几个数据块,但是由于可靠性保证,接收方可以按顺序接收数据块然后重新组成分块之前的数据流,所以TCP看起来就像直接互相传输字节流一样,面向字节流。

3.2 UDP的定义和特点

  • 定义:User Datagram Protocol,即用户数据报协议,是一种传输层通信协议。

    基于UDP的应用层协议有TFTP、SNMP与DNS。

  • 特点:无连接的、不可靠的、面向报文、没有拥塞控制

    • 无连接的:和TCP要建立连接不同,UDP传输数据不需要建立连接,就像写信,在信封写上收信人名称、地址就可以交给邮局发送了,至于能不能送到,就要看邮局的送信能力和送信过程的困难程度了。
    • 不可靠的:因为UDP发出去的数据包发出去就不管了,不管它会不会到达,所以很可能会出现丢包现象,使传输的数据出错。
    • 面向报文:数据报文,就相当于一个数据包,应用层交给UDP多大的数据包,UDP就照样发送,不会像TCP那样拆分。
    • 没有拥塞控制:拥塞,是指到达通信子网中某一部分的分组数量过多,使得该部分网络来不及处理,以致引起这部分乃至整个网络性能下降的现象,严重时甚至会导致网络通信业务陷入停顿,即出现死锁现象,就像交通堵塞一样。TCP建立连接后如果发送的数据因为信道质量的原因不能到达目的地,它会不断重发,有可能导致越来越塞,所以需要一个复杂的原理来控制拥塞。而UDP就没有这个烦恼,发出去就不管了。

应用场景
很多的实时应用(如IP电话、实时视频会议、某些多人同时在线游戏等)要求源主机以很定的速率发送数据,并且允许在网络发生拥塞时候丢失一些数据,但是要求不能有太大的延时,UDP就刚好适合这种要求。

☀ TCP 和 UDP 的优缺点无法简单地、绝对地去做比较:TCP 用于在传输层有必要实现可靠传输的情况;而在一方面,UDP 主要用于那些对高速传输和实时性有较高要求的通信或广播通信。TCP 和 UDP 应该根据应用的目的按需使用。

在说TCP的三次握手和四次挥手之前,我们还有必要来了解一下TCP的报文结构,因为其中的几个字段有助于我们更好的理解三次握手和四次挥手的过程。

4. TCP报文结构

在这里插入图片描述

我属于那种用到什么才学点什么的懒加载式学习,因为学多了我也记不住

所以这里我就挑几个重要字段来记录一下:

  • (1)序号:即seq序号(Sequence number),占32位,用来标识从TCP源端向目的端发送的字节流,发起方发送数据时对此进行标记。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。

  • (2)确认号:即ack序号(Acknowledgment number),占32位,只有 ACK标志位 为1时,确认序号字段才有效,ack=seq+1。是指期望收到对方的下一个报文段的数据的第一个字节的序号。

  • (3)标志位:共有6个标志位,即URG、ACK、PSH、RST、SYN、FIN等,具体含 义如下:

    确认ACK: 当ACK = 1时,确认字段有效,当ACK = 0时,确认字段无效。TCP规定,在连接创建后所有传送的报文段须将ACK置为1

    同步SYN: 若SYN = 1,则表示这是请求建立连接。

    终止FIN: 释放连接。当FIN = 1时,表示此报文段的发送方需要发送的数据已经全部发送完毕,请求断开连接。

    紧急URG: 当URG = 1,表示紧急指针字段有效。此时发送方TCP就将紧急数据插入到本报文的数据的最前面,后面顺序不变,保证将紧急需要发送的最先发送。与最后的紧急指针配合使用。

    推送PSH: 接受方TCP接收到PSH = 1,表示该报文段高于优先级,需要尽快地交付给接受应用程序,不需要等到整个TCP缓存都填满了后在交付。
    复位 RST: 当RST = 1时,表示TCP连接发生严重错误,必须马上释放连接,重新建立新连接。

​ 需要注意的是:
​ (A)不要将确认序号ack与标志位中的ACK搞混了。
​ (B)确认方ack=发起方seq+1,两端配对。

那这个序列号(seq)和确认号 (ack) 有什么作用呢?

答:TCP中可以通过序列号与确认应答提高可靠性。

image

好,有了这些基础,下面我们就来讲TCP的三次握手了~

5. TCP中的三次握手▲▲▲(面试点)

5.1 描述一下TCP中三次握手的流程

在这里插入图片描述

所谓三次握手是指建立一个 TCP 连接时需要客户端和服务器端总共发送三个包以确认连接的建立。

【详细的描述】是这样的:

  • 第一次握手:建立连接。客户端发送连接请求报文段,将SYN位置为1,seq(Sequence Number)为 J ;然后,客户端进入SYN_SEND状态,等待服务器的确认。

  • 第二次握手:服务器端收到数据包后由标志位SYN=1知道客户端请求建立连接,服务器端将标志位SYN和ACK都置为1,ack=J+1,随机产生一个值seq=K,并将该数据包发送给客户端以确认连接请求,服务器端进入SYN_RCVD状态。

  • 第三次握手:客户端收到确认后,检查ack是否为J+1,ACK是否为1,如果正确则将标志位ACK置为1,ack=K+1,并将该数据包发送给服务器端,服务器端检查ack是否为K+1,ACK是否为1,如果正确则连接建立成功,客户端和服务器端进入ESTABLISHED状态,完成三次握手,随后客户端与服务器端之间可以开始传输数据了。

【简单点描述】也就是:

  • 第一次握手 → 客户端请求建立连接。

  • 第二次握手 → 服务端应答客户端,并请求建立连接。

  • 第三次握手 → 客户端针对服务端请求确认应答。

这样就完成TCP三次握手 = 一条TCP连接建立完成 = 可以开始发送数据

注意 1.三次握手期间任何一次未收到对面回复都要重发。

​ 2.最后一个确认报文段发送完毕以后,客户端和服务器端都进入ESTABLISHED状态。

5.2 为什么TCP建立连接需要三次握手?

为了防止服务器端因为接收了早已失效的连接请求报文从而一直等待客户端请求,从而浪费资源。

再分析具体一点就是:

  • “已失效的连接请求报文段”的产生在这样一种情况下:Client发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server。
  • 这是一个早已失效的报文段。但Server收到此失效的连接请求报文段后,就误认为是Client再次发出的一个新的连接请求。
  • 于是就向Client发出确认报文段,同意建立连接。
  • 假设不采用“三次握手”:只要Server发出确认,新的连接就建立了。
  • 由于现在Client并没有发出建立连接的请求,因此不会向Server发送数据。
  • 但Server却以为新的运输连接已经建立,并一直等待Client发来数据。>- 这样,Server的资源就白白浪费掉了。

而采用了三次握手之后,上述问题就不会发生。一切都会按照下面的正确脚步进行:

  • Client不会向Server的确认发出确认
  • Server由于收不到确认,就知道Client并没有要求建立连接
  • 所以Server不会等待Client发送数据,资源就没有被浪费

5.3 TCP三次握手有什么漏洞吗(知道即可)

漏洞:☛ SYN洪泛攻击

☛ 定义:

通过网络服务所在的端口发送大量伪造原地址的攻击报文,发送到服务端,造成服务端上的半开连接队列被占满,从而阻止其他用户进行访问。

☛ 原理:

攻击者客户端利用伪造的IP地址向服务端发出请求(第一次握手),而服务端的响应(第二次握手)的报文将永远发送不到真实的客户端,服务端在等待客户端的第三次握手(永远都不会有的),服务端在等待这种半开的连接过程中消耗了资源,如果有成千上万的这种连接,主机资源将被耗尽,从而达到攻击的目的。

☛ 解决方案:

无效连接监控释放

延缓TCB分配方法

防火墙

6.TCP中的四次挥手(面试点▲)

6.1 描述一下TCP中四次挥手的流程

在这里插入图片描述

四次挥手即终止TCP连接,就是指断开一个TCP连接时,需要客户端和服务端总共发送4个包以确认连接的断开。

注意:可以是客户端先发出中断,也可以是服务器端先发出中断。甚至是两方同时发出中断的情况也是有的!

【详细的描述】是这样的:

  • 第一次挥手:客户端发送一个FIN=M,用来关闭客户端到服务器端的数据传送,客户端进入FIN_WAIT_1状态。意思是说"我客户端没有数据要发给你了",但是如果你服务器端还有数据没有发送完成,则不必急着关闭连接,可以继续发送数据。

  • 第二次挥手:服务器端收到FIN后,先发送ack=M+1,告诉客户端,你的请求我收到了,但是我还没准备好,请继续你等我的消息。这个时候客户端就进入FIN_WAIT_2 状态,继续等待服务器端的FIN报文。

  • 第三次挥手:当服务器端确定数据已发送完成,则向客户端发送FIN=N报文,告诉客户端,好了,我这边数据发完了,准备好关闭连接了。服务器端进入LAST_ACK状态。

  • 第四次挥手:客户端收到FIN=N报文后,就知道可以关闭连接了,但是他还是不相信网络,怕服务器端不知道要关闭,所以发送ack=N+1后进入TIME_WAIT状态,如果Server端没有收到ACK则可以重传。服务器端收到ACK后,就知道可以断开连接了。客户端等待了2MSL后依然没有收到回复,则证明服务器端已正常关闭,那好,我客户端也可以关闭连接了。最终完成了四次握手。

【简单点描述】也就是:

  • 第一次挥手:客户端发送关闭请求

  • 第二次挥手:服务端响应客户端关闭请求

  • 第三次挥手:服务端发送关闭请求

  • 第四次挥手:客户端发送关闭确认请求

6.2 为什么TCP释放连接需要四次挥手?

为了保证双方都能通知对方“需要释放连接”,即在释放连接后都无法接收或发送消息给对方

  • 需要明确的是:TCP是全双工模式,这意味着是双向都可以发送、接收的

  • 释放连接的定义是:双方都无法接收或发送消息给对方,是双向的

  • 当主机1发出“释放连接请求”(FIN报文段)时,只是表示主机1已经没有数据要发送 / 数据已经全部发送完毕;

    但是,这个时候主机1还是可以接受来自主机2的数据。

  • 当主机2返回“确认释放连接”信息(ACK报文段)时,表示它已经知道主机1没有数据发送了
    但此时主机2还是可以发送数据给主机1

  • 当主机2也发送了FIN报文段时,即告诉主机1我也没有数据要发送了
    此时,主机1和2已经无法进行通信:主机1无法发送数据给主机2,主机2也无法发送数据给主机1,此时,TCP的连接才算释放

6.3 为什么建立连接是三次握手,而关闭连接却是四次挥手呢,为什么2、3两次不能合并呢?

这是因为服务端在LISTEN状态下,收到建立连接请求的SYN报文后,把ACK和SYN放在一个报文里发送给客户端。而关闭连接时,当收到对方的FIN报文时,仅仅表示对方不再发送数据了但是还能接收数据,己方也未必全部数据都发送给对方了,所以己方可以立即close,也可以发送一些数据给对方后,再发送FIN报文给对方来表示同意现在关闭连接,因此,己方ACK和FIN一般都会分开发送。

7.TCP协议中的窗口机制(拓展,了解一下即可)

在这里插入图片描述

滑动窗口

发送方和接收方都会维护一个数据帧的序列,这个序列被称作窗口。

发送方的窗口大小由接收方确认。

目的

1.确保数据不丢失

​ 如果发送的数据丢失了可以重新发。

2.控制发送速度

​ 控制发送速度,以免接收方的缓存不够大导致溢出,同时控制流量也可以避免网络拥塞。

嗯呐,学习中,如有不正确的地方,希望可以一起讨论呀~

相关文章

网友评论

      本文标题:网络架构系列1--TCP/IP详解

      本文链接:https://www.haomeiwen.com/subject/qwvmactx.html