tcp udp(tcp和udp的区别)

tcp和udp的区别

前端的面试中常常问的TCP和UDP的差异，网上也有好多内容，比方
TCP和UDP的差异
TCP是面向衔接的，UDP是面向无衔接的
UDP程序结构较简略
TCP是面向字节省的，UDP是依据数据报的
TCP确保数据正确性，UDP或许丢包
TCP确保数据次序，UDP不确保
之前也由于面试的原因了解过一下，可是面试官又问了为什么TCP是牢靠传输，一下就泄露了，说不出来了，然后这两天就细心了解了一下这方面的内容，还专门订阅了极客时刻的趣谈网络协议，因而，这篇文章首要依据趣谈网络协议和自己的了解。
1.UDP
要想了解TCP和UDP的差异，首要要了解什么是TCP，什么是UDP
TCP和UDP是传输层的两个协议
咱们来看一下UDP的包头
UDP包头
由上图能够看出，UDP除了端口号，根本啥都没有了。假如没有这两个端口号，数据就不知道该发给哪个使用。
所以UDP就像一个小孩子，特别简略，有如下三个特色
UDP的特色
交流简略，不需求大量的数据结构，处理逻辑和包头字段
轻信他人。它不会树立衔接，可是会监听这个当地，谁都能够传给它数据，它也能够传给任何人数据，乃至能够一起传给多个人数据。
愣头青，干事不懂变通。不会依据网络的状况进行拥塞操控，无论是否丢包，它该怎样发还是怎样发
由于UDP是”小孩子”，所以处理的是一些没那么难的项目，而且就算失利的也能接纳。依据这些特色的话，UDP能够使用在如下场景中
UDP的首要使用场景
需求资源少，网络状况安稳的内网，或许关于丢包不敏感的使用，比方DHCP便是依据UDP协议的。
不需求1对1交流，树立衔接，而是能够播送的使用。由于它不面向衔接，所以能够做到一对多，承担播送或许多播的协议。
需求处理速度快，能够容忍丢包，可是即使网络拥塞，也毫不退缩，一往无前的时分
依据UDP的几个比方
直播。直播对实时性的要求比较高，宁可丢包，也不要卡顿的，所以许多直播使用都依据UDP完结了自己的视频传输协议
实时游戏。游戏的特色也是实时性比较高，在这种状况下，选用自定义的牢靠的UDP协议，自定义重传战略，能够把产生的推迟降到最低，削减网络问题对游戏形成的影响
物联网。一方面，物联网领域中止资源少，很或许知识个很小的嵌入式系统，而维护TCP协议的代价太大了；另一方面，物联网对实时性的要求也特别高。比方Google旗下的Nest简历ThreadGroup，推出了物联网通信协议Thread，便是依据UDP协议的
还有一些，可是写的太多了也记不住，所以首要记住这几个就够了
2.TCP
首要是TCP的包头格局
TCP包头
TCP的包头有哪些内容，分别有什么用
首要，源端口和目标端口是不可少的。
接下来是包的序号。首要是为了解决乱序问题。不编好号怎样知道哪个先来，哪个后到
承认序号。发出去的包应该有承认，这样能知道对方是否收到，假如没收到就应该从头发送，这个解决的是不丢包的问题
状况位。SYN是建议一个链接，ACK是回复，RST是从头衔接，FIN是完毕衔接。由于TCP是面向衔接的，因而需求两边维护衔接的状况，这些状况位的包会引起两边的状况改变
窗口巨细，TCP要做流量操控，需求通信两边各声明一个窗口，标识自己当时的处理才能。
经过对TCP头的解析，咱们知道要把握TCP协议，应该要点重视以下问题：
次序问题
丢包问题
衔接维护
流量操控
拥塞操控
2.1TCP的三次握手
所有的问题，首要都要树立衔接，所以首要是衔接维护的问题
TCP的树立衔接称为三次握手，能够简略了解为下面这种状况
A：您好，我是A
B：您好A，我是B
A：您好B
至于为什么是三次握手我这里就不细讲了，能够看其他人的博客，总结的话便是通信两边全都有来有回
关于A来说它发出恳求，并收到了B的响应，关于B来说它响应了A的恳求，而且也接纳到了响应。
TCP的三次握手除了树立衔接外，首要还是为了交流TCP包的序号问题。
A告知B，我建议的包的序号是从哪个号开端的，B同样也告知A，B建议的包的序号是从哪个号开端的。
两边树立衔接之后需求共同维护一个状况机，在树立衔接的过程中，两边的状况改变时序图如下所示
状况改变时序图
这是网上常常见到的一张图，刚开端的时分，客户端和服务器都处于CLOSED状况，先是服务端自动监听某个端口，处于LISTEN状况。然后客户端自动建议衔接SYN，之后处于SYN-SENT状况。服务端接纳了建议的衔接，回来SYN，而且ACK(承认)客户端的SYN，之后处于SYN-SENT状况。客户端接纳到服务端发送的SYN和ACK之后，发送ACK的ACK，之后就处于ESTAVLISHED状况，由于它一发一收成功了。服务端收到ACK的ACK之后，也处于ESTABLISHED状况，由于它也一发一收了。
2.2TCP四次挥手
说完树立衔接，再说下断开衔接，也被称为四次挥手，能够简略了解如下
A：B啊，我不想玩了
B：哦，你不想玩了啊，我知道了
这个时分，仅仅A不想玩了，即不再发送数据，可是B或许还有未发送完的数据，所以需求等候B也自动封闭。
B：A啊，好吧，我也不玩了，拜拜
A：好的，拜拜
这样整个衔接就封闭了，当然上面仅仅正常的状况，也有些非正常的状况（比方A说完不玩了，直接跑路，B建议的完毕得不到A的回答，不知道该怎样办或则B直接跑路A不知道该怎样办），TCP协议专门设计了几个状况来处理这些非正常状况
断开衔接状况时序图
断开的时分，当A说不玩了，就进入FIN_WAIT_1的状况，B收到A不玩了的音讯后，进入CLOSE_WAIT的状况。
A收到B说知道了，就进入FIN_WAIT_2的状况，假如B直接跑路，则A永远处与这个状况。TCP协议里边并没有对这个状况的处理，但Linux有，能够调整tcp_fin_timeout这个参数，设置一个超时时刻。
假如B没有跑路，A接纳到B的不玩了恳求之后，从FIN_WAIT_2状况完毕，按说A能够跑路了，可是假如B没有接纳到A跑路的ACK呢，就再也接纳不到了，所以这时分A需求等候一段时刻，由于假如B没接纳到A的ACK的话会从头发送给A，所以A的等候时刻需求足够长。
2.3累计承认
TCP如何完结牢靠传输?
首要为了确保次序性，每个包都有一个ID。在树立衔接的时分会商定开始ID是什么，然后按照ID一个个发送，为了确保不丢包，需求对发送的包都要进行应对，当然，这个应对不是一个一个来的，而是会应对某个之前的ID，表示都收到了，这种形式成为累计应对或累计承认。
为了记载所有发送的包和接纳的包，TCP需求发送端和接纳端分别来缓存这些记载，发送端的缓存里是按照包的ID一个个摆放，依据处理的状况分红四个部分
发送而且承认的
发送没有承认的
没有发送等候发送的
没有发送而且暂时不会发送的
这里的第三部分和第四部分就属于流量操控的内容
在TCP里，接纳端会给发送端报一个窗口巨细，叫Advertisedwindow。这个窗口应该等于上面的第二部分加上第三部分，超越这个窗口，接纳端做不过来，就不能发送了
所以，发送端要坚持下面的数据结构
发送端数据结构
关于接纳端来讲，它的缓存里边的内容要简略一些
接纳而且承认过的
还没接纳，可是立刻就能接纳的
还没接纳，但也无法接纳的
对应的数据结构如下
接纳端的数据结构
2.4次序问题和丢包问题
结合上面的图看，在发送端，1、2、3已发送并承认；4、5、6、7、8、9都是发送了还没承认；10、11、12是还没发出的；13、14、15是接纳方没有空间，不准备发的。
在接纳端来看，1、2、3、4、5是现已完结ACK可是还没读取的；6、7是等候接纳的；8、9是现已接纳还没有ACK的。
发送端和接纳端当时的状况如下：
1、2、3没有问题，两边达成了共同
4、5接纳方说ACK了，可是发送方还没收到
6、7、8、9肯定都发了，可是8、9现已到了，6、7没到，呈现了乱序，缓存着可是没办法ACK。
依据这个比方能够知道次序问题和丢包问题都有或许存在，所以咱们先来看承认与重传机制。
假定4的承认收到了，5的ACK丢了，6、7的数据包丢了，该怎样办？
一种方法是超时重试，即对每一个发送了可是没有ACK的包设定一个定时器，超越了必定的事件就从头测验。这个时刻有必要大于往复时刻，但也不宜过长，不然超时时刻变长，访问就变慢了。
假如过一段时刻，5、6、7都超时了就会从头发送。接纳方发现5原来接纳过，所以丢掉5；6收到了，发送ACK，要求下一个是7，7不幸又丢了。当7再次超时的时分，TCP的战略是超时刻隔加倍。每逢遇到一次超时重传的时分，都会讲下一次超时时刻距离设为从前值的两倍。
超时重传的机制是超时周期或许相对较长，是否有更快的方式呢？
有一个快速重传的机制，即当接纳方接纳到一个序号大于希望的报文段时，就检测到了数据流之间的距离，所以发送三个冗余的ACK，客户端接纳到之后，知道数据报丢掉，所以重传丢掉的报文段。
例如，接纳方发现6、8、9都接纳了，可是7没来，所以肯定丢了，所以发送三个6的ACK，要求下一个是7。客户端接纳到3个，就会发现7的确又丢了，不等超时，立刻重发。
2.5流量操控的问题
在流量操控的机制里边，在关于包的承认中，会带着一个窗口的巨细
简略的说一下便是接纳端在发送ACK的时分会带上缓冲区的窗口巨细，可是一般在窗口到达必定巨细才会更新窗口，由于每次都更新的话，刚空下来就又被填满了
2.6拥塞操控的问题
也是经过窗口的巨细来操控的，可是检测网络满不满是个挺难的工作，所以TCP发送包常常被比喻成往谁管理灌水，所以拥塞操控便是在不阻塞，不丢包的状况下尽或许的发挥带宽。
水管有粗细，网络有带宽，即每秒钟能发送多少数据；水管有长度，端到端有时延。抱负状况下，水管里边的水=水管粗细*水管长度。关于网络上，通道的容量=带宽*往复时延。
假如咱们设置发送窗口，使得发送但未承认的包为通道的容量，就能撑满整个管道。
如图所示，假定往复时刻为8秒，去4秒，回4秒，每秒发送一个包，现已过去了8秒，则8个包都发出去了，其间前四个现已到达接纳端，可是ACK还没回来，不能算发送成功，5-8后四个包还在路上，还没被接纳，这个时分，管道正好撑满，在发送端，已发送未承认的8个包，正好等于带宽，也即每秒发送一个包，也即每秒发送一个包，乘以来回时刻8秒。
假如在这个基础上调大窗口，使得单位时刻能够发送更多的包，那么会呈现接纳端处理不过来，多出来的包会被丢掉，这个时分，咱们能够添加一个缓存，可是缓存里边的包4秒内肯定达不到接纳端课，它的缺点会添加时延，假如时延到达必定程度就会超时重传
TCP拥塞操控首要来避免两种现象，包丢掉和超时重传，一旦呈现了这些现象说明发送的太快了，要慢一点。
详细的方法便是发送端慢启动，比方倒水，刚开端倒的很慢，逐渐变快。然后设置一个阈值，当超越这个值的时分就要慢下来
慢下来还是在增长，这时分就或许水满则溢，呈现拥塞，需求下降倒水的速度，等水渐渐渗下去。
拥塞的一种表现是丢包，需求超时重传，这个时分，选用快速重传算法，将当时速度变为一半。所以速度还是在比较高的值，也没有一夜回到解放前。