点击上方“千锋Java学院”，选择“置顶公众号”
每天一道面试模拟真题及解析
课前导读
●回复"每日一练"获取以前的题目，持续更新！
●我希望大家积极参与！有什么不懂可以加小千微信进行讨论
★把面试准备工作，拆分、融入到平时每天
tcp和udp的区别？
参考答案：
TCP/IP 协议是一个协议簇，包括很多协议。命名为 TCP/IP 协议的原因是 TCP 和 IP 这两个协议非常重要，应用很广。
TCP 和 UDP 都是 TCP/IP 协议簇里的一员。TCP，Transmission Control Protocol 的缩写，即传输控制协议。
面向连接，即必须在双方建立可靠连接之后，才会收发数据
信息包头 20 个字节
建立可靠连接需要经过3次握手
断开连接需要经过4次挥手
需要维护连接状态
报文头里面的确认序号、累计确认及超时重传机制能保证不丢包、不重复、按序到达
拥有流量控制及拥塞控制的机制
UDP，User Data Protocol 的缩写，即用户数据报协议。
不建立可靠连接，无需维护连接状态
信息包头 8 个字节
接收端，UDP 把消息段放在队列中，应用程序从队列读消息
不受拥挤控制算法的调节
传送数据的速度受应用软件生成数据的速率、传输带宽、源端和终端主机性能的限制
面向数据报，不保证接收端一定能收到
▼点击阅读原文抢预约免费试听课程名额

	

一、TCP协议：
       位于传输层， 提供可靠的字节流服务。所谓的字节流服务(Byte Stream Service) 是指， 为了方便传输， 将大块数据分割成以报文段(segment) 为单位的数据包进行管理。而可靠的传输服务是指， 能够把数据准确可靠地传给对方。即TCP 协议为了更容易传送大数据才把数据分割， 而且 TCP 协议能够确认数据最终是否送达到对方。所以，TCP连接相当于两根管道(一个用于服务器到客户端，一个用于客户端到服务器)，管道里面数据传输是通过字节码传输，传输是有序的，每个字节都是一个一个来传输。
(1)、三次握手：握手过程中使用了 TCP 的标志(flag) —— SYN(synchronize) 和ACK(acknowledgement) 。
第一次握手：建立连接时，客户端A发送SYN包(SYN=j)到服务器B，并进入SYN_SEND状态，等待服务器B确认。
第二次握手：服务器B收到SYN包，必须确认客户A的SYN(ACK=j+1)，同时自己也发送一个SYN包(SYN=k)，即SYN+ACK包，此时服务器B进入SYN_RECV状态。
第三次握手：客户端A收到服务器B的SYN＋ACK包，向服务器B发送确认包ACK(ACK=k+1)，此包发送完毕，完成三次握手。
若在握手过程中某个阶段莫名中断， TCP 协议会再次以相同的顺序发送相同的数据包。 (2)、四次挥手：由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。先进行关闭的一方将执行主动关闭，而另一方被动关闭。
客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送。
服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。
服务器B关闭与客户端A的连接，发送一个FIN给客户端A。
客户端A发回ACK报文确认，并将确认序号设置为收到序号加1。
三次握手和四次挥手：在TCP连接中，服务器端的SYN和ACK向客户端发送是一次性发送的，而在断开连接的过程中， B端向A
端发送的ACK和FIN是分两次发送的。因为在B端接收到A端的FIN后， B端可能还有数据要传输，所以先发送ACK，等B端处理完自己的事情后就可以发送FIN断开连接了。
(3)、深入理解TCP连接： 
由于TCP是全双工的，因此在每一个方向都必须单独关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个FIN只意味着这个方向上没有数据流动，一个TCP连接在接收到一个FIN后仍能发送数据。首先进行关
闭的一方将执行主动关闭，而另一方执行被动关闭。
TCP协议的连接是全双工连接，一个TCP连接存在双向的读写通道。简单来说，是“先关读，再关写” ，总共需要4个阶段。以客户机发起关闭连接为例：1.服务器读通道关闭；2.客户端写通道关闭；3.客户端读通道关闭；4.服务器写通道关闭。
关闭行为是在发起方数据发送完毕之后，给对方发出一个FIN(finish)数据段，直到接收到对方发送的FIN,且对方收到了接收确认的ACK之后，双方的数据通信完全结束，过程中每次都需要返回确认数据段ACK。
(4)、TCP使用滑动窗口机制来进行流量控制。
建立连接时，各端分配一个缓冲区用来存储接收的数据，并将缓冲区的尺寸发送给另一端。接收方发送的确认消息中包含了自己剩余的缓冲区尺寸。剩余缓冲区空间的数量叫做窗口。其实就是建立连接的双虎互相知道彼此剩余的缓冲区大小。
 (5)、拥塞控制
拥塞控制：防止过多的数据注入到网路中，这样可以使网络中的路由器或链路不至于阻塞。拥塞控制是一个全局性的过程，和流量控制不同，流量控制是点对点的控制。
1、慢开始：发送方维持一个叫做拥塞窗口cwnd(congestion window)的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态的变化。发送方让自己的发送窗口等于拥塞窗口，另外考虑到接收方的接收能力，发送窗口可能小于拥塞窗口。思路就是：不要一开始就发送大量的数据，先试探一下网络的拥塞程度，也就是说由小到大增加拥塞窗口的大小。
为了防止cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh状态变量。ssthresh的方法如下：
当cwnd < ssthresh时，开始使用慢开始算法；当cwnd > ssthresh, 改用拥塞避免算法；当cwnd = ssthresh时，慢开始与拥塞算法任意。
 2.拥塞避免：
拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍，这样拥塞窗口按照线性规律缓慢增长。无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞(其根据就是没有收到确认，虽然没有收到确认可能是其他原因的分组丢失，但是因为⽆法判定，所以都当作拥塞处理)，就把慢开始门限设置为出现拥塞时的发送窗口的一半，然后把拥塞窗口设置为1，执行慢开始算法：
此外，还有快速重传和快速恢复，停止-等待协议，回退N帧协议，选择重传协议等。 
二、UDP协议：
无连接协议，也称透明协议，也位于传输层。
两者区别：
1) TCP提供面向连接的传输，通信前要先建立连接(三次握手机制)；UDP提供无连接的传输，通信前不需要建立连接。
2) TCP提供可靠的传输(有序，无差错，不丢失，不重复)；UDP提供不可靠的传输。
3) TCP面向字节流的传输，因此它能将信息分割成组，并在接收端将其重组；UDP是面向数据报的传输，没有分组开销。
4) TCP提供拥塞控制和流量控制机制；UDP不提供拥塞控制和流量控制机制。

三、长连接和短连接
       HTTP的长连接和短连接本质上是TCP长连接和短连接。HTTP属于应用层协议，在传输层使用TCP协议，在网络层使用IP协议。IP协议主要解决网络路由和寻址问题，TCP协议主要解决如何在IP层之上可靠地传递数据包，使得网络上接收端收到发送端所发出的所有包，并且顺序与发送顺序一致。TCP协议是可靠的、面向连接的。
在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源(如JavaScript文件、图像文件、CSS文件等)，每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。
而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：
Connection:keep-alive
在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件(如Apache)中设定这个时间。实现长连接需要客户端和服务端都支持长连接。
HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

	

一：TCP 和 UDP 之间的区别
↓↓↓
好了，我知道有些童鞋想到我们发过的旧图了 
往期趣图(点击下方图片可跳转阅读)
感觉是不是很爽，图上UDP看起来那么暴力，但是使用起来感觉还好，内网比较少丢包
二、主要丢包原因
1、接收端处理时间过长导致丢包：调用recv方法接收端收到数据后，处理数据花了一些时间，处理完后再次调用recv方法，在这二次调用间隔里,发过来的包可能丢失。对于这种情况可以修改接收端，将包接收后存入一个缓冲区，然后迅速返回继续recv。
2、发送的包巨大丢包：虽然send方法会帮你做大包切割成小包发送的事情，但包太大也不行。例如超过50K的一个udp包，不切割直接通过send方法发送也会导致这个包丢失。这种情况需要切割成小包再逐个send。
3、发送的包较大，超过接受者缓存导致丢包：包超过mtu size数倍，几个大的udp包可能会超过接收者的缓冲，导致丢包。这种情况可以设置socket接收缓冲。以前遇到过这种问题，我把接收缓冲设置成64K就解决了。
int nRecvBuf=32*1024;//设置为32K
setsockopt(s,SOL_SOCKET,SO_RCVBUF,(const char*)&nRecvBuf,sizeof(int));
4、发送的包频率太快：虽然每个包的大小都小于mtu size 但是频率太快，例如40多个mut size的包连续发送中间不sleep，也有可能导致丢包。这种情况也有时可以通过设置socket接收缓冲解决，但有时解决不了。所以在发送频率过快的时候还是考虑sleep一下吧。
5、局域网内不丢包，公网上丢包。这个问题我也是通过切割小包并sleep发送解决的。如果流量太大，这个办法也不灵了。总之udp丢包总是会有的，如果出现了用我的方法解决不了，还有这个几个方法：要么减小流量，要么换tcp协议传输，要么做丢包重传的工作。
二、具体问题分析
1.发送频率过高导致丢包
很多人会不理解发送速度过快为什么会产生丢包，原因就是UDP的SendTo不会造成线程阻塞，也就是说，UDP的SentTo不会像TCP中的SendTo那样，直到数据完全发送才会return回调用函数，它不保证当执行下一条语句时数据是否被发送。(SendTo方法是异步的)这样，如果要发送的数据过多或者过大，那么在缓冲区满的那个瞬间要发送的报文就很有可能被丢失。至于对“过快”的解释，作者这样说：“A few packets a second are not an issue; hundreds or thousands may be an issue.”(一秒钟几个数据包不算什么，但是一秒钟成百上千的数据包就不好办了)。要解决接收方丢包的问题很简单，首先要保证程序执行后马上开始监听(如果数据包不确定什么时候发过来的话)，其次，要在收到一个数据包后最短的时间内重新回到监听状态，其间要尽量避免复杂的操作(比较好的解决办法是使用多线程回调机制)。
2.报文过大丢包
至于报文过大的问题，可以通过控制报文大小来解决，使得每个报文的长度小于MTU。以太网的MTU通常是1500 bytes，其他一些诸如拨号连接的网络MTU值为1280 bytes，如果使用speaking这样很难得到MTU的网络，那么最好将报文长度控制在1280 bytes以下。
3.发送方丢包
发送方丢包：内部缓冲区(internal buffers)已满，并且发送速度过快(即发送两个报文之间的间隔过短)； 接收方丢包：Socket未开始监听； 虽然UDP的报文长度最大可以达到64 kb，但是当报文过大时，稳定性会大大减弱。这是因为当报文过大时会被分割，使得每个分割块(翻译可能有误差，原文是fragmentation)的长度小于MTU，然后分别发送，并在接收方重新组合(reassemble)，但是如果其中一个报文丢失，那么其他已收到的报文都无法返回给程序，也就无法得到完整的数据了。
 三、测试TCP,UDP 端口是否通常的小技巧
是不是经常遇见这样的场景：xx运维：你看看你是不是把服务器8008端口阿里云端口没开，我程序明明跑起来的，在服务器上能看到端口
运维同学：NND,没事就说我的问题
上服务器一看，云安全策略也是打开，firewall也是端口打开的，咋就不通了呢，这事说不清，甩锅也甩不清，别慌，把他原来的8008端口进行停止
然后：
python2 -m SimpleHTTPServer 8008telnet xx.xx.xx.xx 8008
发现立马通了，那就直接告诉他代码的问题吧(一般是一些rpc端口限制了ip)
再来说说UDP，在区块链中，节点与节点之间的通信常常是p2p,会发送UDP命令，但是有的时候发现节点跑不起来，看日志UDP命令没发送，那怎么测试UDP端口是不是通的呢，百度一下，它一般告诉你:
netcat -u x.x.x.x 8008
你本地机器一试，果然是通的，确实好用，但是你远程测试的时候，咋发现提示成功，节点之间还是不发送udp呢？看来光用这还不行，那想一种办法来监控服务器是否收到该端口的UDP包了，于是tcpdump上场了
tcpdump udp port 8008

1、Modbus协议属于应用层(OSI模型第7层)协议，TCP/UDP协议属于传输层(OSI模型第4层)协议，两者层级不是并列关系。
打个比喻，Modbus协议就像公司里的总经理，TCP/UDP协议就像公司里的轿车、商务车。某天总经理要到机场去乘飞机，他可以选择：1)自己开轿车去，2)让司机开商务车送去，3)搭的士/公交车过去。若选择1)，那就是总经理-轿车的关系，Modbus TCP协议就形同这种关系。若选择3)，就形同另外的Modbus RTU/ASCII协议的关系。
2、Modbus协议是一种已广泛应用于当今工业控制领域的通用通讯协议。通过此协议，控制器相互之间、或控制器经由网络(如以太网)可以和其它设备之间进行通信。Modbus协议使用的是主从通讯技术，即由主设备主动查询和操作从设备。一般将主控设备方所使用的协议称为Modbus Master，从设备方使用的协议称为Modbus Slave。典型的主设备包括工控机和工业控制器等;典型的从设备如PLC可编程控制器等。Modbus通讯物理接口可以选用串口(包括RS232和RS485)，也可以选择以太网口。
3、而Modbus TCP协议则是在RTU协议上加一个MBAP报文头，由于TCP是基于可靠连接的服务，RTU协议中的CRC校验码就不再需要，所以在Modbus TCP协议中是没有CRC校验码，用一句比较通俗的话说就是：Modbus TCP协议就是Modbus RTU协议在前面加上五个0以及一个6，然后去掉两个CRC校验码字节就OK.虽然这句话说得不是特别准确，但是也基本上把RTU与TCP之间的区别说得比较清楚了。