• 网络基础:TCP协议、UDP协议、均属于传输层协议;TCP和UDP协议有何不同?


    传输层

    • 传输层的主要工作是定义端口,标识应用程序身份,并将数据包交给对应的应用程序实现端口到端口的通信,并且传输层引入了TCP/UDP协议。

    1. 如果有大量数据包、数据包大?时间很长,网络中断,怎么控制重新传输?怎么确保数据包正确完整---传输层

    • 传输层封装数据包,通过定义的 TCP、UDP 协议实现按序一个一个发送,保证数据完整正确性;    

    2. QQ发消息,你必须使用QQ接受消息,才可以正常通信;但是电脑中不是只运行了QQ,还有其他程序,怎么确定由谁来处理消息

    • 传输层定义端口的概念-- HTTP-tcp-80端口、https是tcp的443端口?--交给特定应用处理

    TCP协议

    • TCP (Transmission Control Protocol)传输控制协议,顾名思义,就是要对数据的传输进行一定的控制.

        

    上图为 TCP协议的基本信息

    • 源目端口:源端口=本地端口、目的端口=目标主机端口;-----寻找应用的作用
    • 序号:TCP 数据包很大的时候,需要分段(比如分为3段),进行三段分开发送;我怎么确认这些碎片的顺序,就会用到序号,到达目的主机时需要进行重组,重组后才可以使用这些数据
    •  确认号:答复确认消息---比如微信发红包后不知道对方有没有收到,需要给我反馈。没有收到也是一个反馈,收到了就会收到确认消息
    •  标志位:
    • ACK=1(灯亮-ACK消息-回应消息)、
    • FIN=0(灯不亮):(结束连接的包需要把 FIN 置位 1)
    • SYN=1 什么类型的包:发起连接请求的包(sym包)、接受请求的包都需要把 SYN 置位 1,FIN=1(结束连接的包需要把 FIN 置位 1)

         

    客户端 client 和 服务器 server 初始都是关闭状态
    客户端茫茫人海中看到了服务器,要服务器进行通信,通信之前需要进行连接,连接之前需要通过三次握手来建立连接

    一次握手:

    • 客户端要给服务器发起连接,消息内包括:什么类型的消息 SYN=1(亮灯)说明是一个发起连接请求的包请求报文,还会带一个编号是J(seq=j),服务器收到消息(星宝SYN=1),后服务器状态会发生改变Sym_REVD,说明我被客户端给撩了;

    二次握手:

    • 服务器给客户端回应,回应要发(安可包)ACK=1(亮灯)SYN =1,会把你的确认号带着ack=j+1,和服务器自己的序列号seq=k-------后状态会发生改变Sym_REVD

    三次握手:

    • 客户端需要回应服务器,我应经收到了你的消息是确认包:ACK=1(确认包)ack=k+1(基于服务器的标识)------已建立链接

    三次握手比如:

    男生     女生

    -------------------> 认识你,交往请求消息
    <------------------- 我知道了,我也同意--确认消息
    -------------------> 我也知道,开心~~牵手成功! ! ! |        三次挥手建立链接之后,就可以发送数据 

    ===========  建立链接之后,经过一段时间,需要断开链接

    断开连接需要 FIN = 1(译:份包)

    • 客户端告诉服务器我们要分手请求:FIN=1,swq=n
    • 服务器回应客户端可以:回应包ACK=1,序列号seq=n+1
    • 服务器也发给客户端一个分手请求:FIN=1,swq=m
    • 客户端回应服务器拜拜就拜拜:回应包 ACK=1,seq=m+1
    1. 对不起,我不喜欢你了
    2. 好的,我知道你不喜欢我了
    3. 你知道了,那分手吧,再见
    4. 好吧,分手吧,再也不见

    整体流程:

    1、TCP 协议 和 UDP 协议的区别?

    TCP 协议 和 UDP协议,都是传输层的两个协议,它们的区别主要有一下三个方面来体现:

    第一,TCP协议是面向连接的,也就是说向我们在打电话之前一样,要先建一个拨号连接;

       而 UDP协议是面向无连接的,就是说在发送顺序之前,UDP不需要建立链接;

    第二,TCP协议是一个可靠的传输协议,它可以保证传输的一个正确性,保证我们的不丢包不重复,而且数据是按顺序到达的;

      而 UDP协议是一个不可靠的协议,它是不保证我们的数据能够可靠完整的到达,他只是尽最大的努力去完成交付的;

    第三,因为 TCP协议的以上两个特点,所以 TCP协议的传输效率会比较低;而对应的 UDP协议传输效率会比较高;

    如果有一些场景,它注重一个传输速度,而不在乎丢包的话,一般会选择 UDP协议来进行传输;比如:ip电话、流媒体等

    2、TCP 协议的三次握手过程?

    TCP协议 在建立链接的时候,需要进行三次握手的过程,

    第一次握手,是客户端向服务器端发起的,这是用来发起一个链接建立的请求,那么这个报文中的 SYN 为会被标记为:1,所以我们把它常叫做 SYN包;

    第二次握手,是由服务器向客户端发起的,是来确认服务器的一个请求链接的,这个报文中的 ACK位 还有 SYN位都被标记为:1,所以常叫做 SYN-ACK 报文;

    第三次握手,是客户端向服务器发起的,这是岁服务器的上一个报文的一个确认报文,这个报文中的一个 ACK位被标记为:1,所以常叫做 ACK 包;

    以上就是 TCP 协议的三次握手的一个过程;

    3、TCP 协议的四次挥手过程?

    当 TCP协议 完成了数据的发送之后,就会尝试去断开链接,此时会经历四次挥手的过程:

    第一次挥手:是客户端向服务器发起的,这个时候客户端已经完成了数据发送,会发起一个包,去进行一个链接断开的请求,这个报文中的 FIN位 被标记为:1,所以叫做 FIN 包;

    第二次挥手:是服务器发送给客户端的,这个报文是用来确认上一个客户端用来断开链接请求的一个报文,所以它是一个 ACK 报文;

    第三次挥手:是服务器发送给客户端的,那么这个时候服务的数据,也发送完毕的话,他也会想客户端发起一个断开连接的请求,在这个报文中的 FIN位 也被标记为:1,所以是一个 FIN 包;

    第四次挥手:是客户端发送给服务器的,是用来确认服务器的上一个断开连接的一个请求报文,所以这次挥手也是一个 ACK 报文;

    以上就是 TCP 协议四次挥手的一个过程;

    4、为什么握手需要三次,挥手却要四次?

    TCP 三次握手的过程是它建立链接的过程,建立链接我只需要确认客户端和服务器都在,双方可以通信就可以了,所以握手需要三次;

    但是四次挥手,是 TCP 结束了数据发送要断开链接的时候的一个过程,所以我要确保,我即结束了发送数据,也结束了接受数据,

    开始咱们的客户端结束了数据发送,他回去告知服务器,那这个时候我们的客户端,其实还是可以接受数据的,服务器收到客户端结束发送数据的请求之后,客户端只是会停止去接收数据,

    但是此时服务器其实还可以再发送数据的,所以如果服务器它也发送完了,那就需要你想客户端发送一次,FIN包 来告知客户端,其实我的数据也发送完了,我也要断开连接了;

    那此时客户端收到了服务器这个 FIN包之后,那么客户端也会进行一个确认,此时然后双方才都会去,关闭发送和接受的一个通道;

    所以挥手需要四次

    UDP协议

    • UDP (User Datagram Protocol)用户数据报协议。
    • UDP 不需要连接---无连接协议 -- 不可靠的协议
    • 目的:速度快  ---  但是有些丢包
    • 什么场景:
      • 视屏、IP电话、流媒体  ---  不在乎丢包,只要不卡
    • 什么协议使用 UDP 连接
      • VOIP电话、DNS(域名解析协议)、SNMP(简单网络管理协议)、DHCP(动态分配地址)

        

     TCP  vs  UDP

      tcp 有很正规的握手和挥手的链接过程,所以是面向连接的协议;http 是基于tcp80端口的可靠的应用层协议;tcp 是可靠的 每个包都标了一个记号,这个包丢了还可以进行重传;如果传输数据量比较大时 需要可靠的场景进行传输;速度慢没关系,必须可靠;

      udp 是面向非连接的,会丢包,不可靠的;传输量小,但是速度很快;要求速度快,丢包了也无所谓;

      

    *******请大家尊重原创,如要转载,请注明出处:转载自:https://www.cnblogs.com/shouhu/   谢谢!!******* 

  • 相关阅读:
    Flex 布局语法教程
    2017年总结的前端文章——border属性的多方位应用和实现自适应三角形
    html 里 checkbox里 只要选中就会自动添加checked=“checked”么?
    jQuery遍历DOM
    checkbox 全选操作
    ubuntu下安装jdk
    ubuntu下安装nodejs
    nodejs express route 的用法
    聊天室业务分析
    一般使用场景
  • 原文地址:https://www.cnblogs.com/shouhu/p/12163238.html
Copyright © 2020-2023  润新知