计算机网络--TCP，UDP面试精简总结
计算机网络--TCP，UDP面试精简总结
TCP：Transmission Control Protocol 传输控制协议TCP是一种面向连接（连接导向）的、可靠的、基于字节流的运输层（Transport layer）通信协议
三次握手与四次挥手图解：
上图的名词解释
SYN：请求同步。它表示建立连接。TCP规定SYN=1时不能携带数据，但要消耗一个序号, 因此随机选取一个序列号为seq=x 数据包（该数据包里就是一个标记seq，并没有任何有效的数据）。
ACK ：确认同步。它表示响应（都能响应了 那肯定上一步就连接成功了啊，所以说ACK=1代表确认连接成功啦）。
因此SYN和ACK同时为1，表示建立连接之后的响应；而只是单个的SYN=1，表示的只是建立连接。
seq： (sequence number) 数据包本身的序列号。它是发送端数据包的初始序号。seq=x 表示发送端数据包的初始序号为x（seq = 0 就代表这是第0号帧）。
ack：(acknowledge number) 确认编号。它是对这次收到数据包的确认，以及对下次收到数据包的期待。ack=x+1表示 我方 到 x为止的所有数据都已正确收到，且我方告知 对方：我期待你下次给我发送包的初始序号(seq)是x+1。
为了方便记忆，可以这么理解：SYN/ACK是TCP协议层面的标记，而seq/ack是数据层面的标记。：
三次握手（我要和你建立链接，你真的要和我建立链接么，我真的要和你建立链接，成功）
-
第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。
-
第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。
-
第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了
四次挥手（我要和你断开链接；好的，断吧。我也要和你断开链接；好的，断吧）：
-
第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
-
第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。此时TCP链接处于半关闭状态，即客户端已经没有要发送的数据了，但服务端若发送数据，则客户端仍要接收。
-
第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
-
第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。
TCP三次握手 过程
（ 1 ）首先Client向Server发送连接：SYN = 1, seq=x；
因为要建立连接，所以SYN=1；又因为TCP规定SYN=1时不能携带数据，但要消耗一个序号, 所以Client随机选取一个初始序号seq=x。（因为并没有响应动作，所以这里没ACK什么事，我们就认为ACK=0吧）
发送后Client进入syn_sent状态，表示客户端等待服务器的回复。
（2）Server收到请求后 再向Client发送确认：SYN=1, ACK=1, seq=y, ack=x+1；
因为Server建立连接后做出了响应，所以SYN=1, ACK=1。因为TCP规定SYN=1时不能携带数据，但要消耗一个序号, 所以Server随机选取一个初始序号seq=y。又因为Server到 x为止的所有数据都已正确收到了，且Server告诉Client：我期待你下次给我发送包的初始序号(seq)是x+1，所以ack=x+1。
发送后服务器进入syn_rcvd，表示服务器已经收到Client的连接请求，等待Client的确认。
（3）Client收到确认后还需再次发送确认，同时携带要发送给Server的数据：ACK=1, seq=x+1, ack= y+1；连接建立
因为有 响应 动作，所以ACK=1(因为要携带发送的数据，所以这儿没SYN什么事)。因为(2)中Server 已经告诉了这次它想收到包的初始序列号是x+1，所以初始序号为seq=x+1。又因为Client到 y为止的所有数据都已正确收到了，准备接收序列号为y+1的包，所以ack=y+1。
Server收到后，这个TCP连接就进入Established状态，就可以发起http请求了。
常见问题
为什么不能改成两次握手？
有人会困惑为什么要进行三次握手呢（两次确认）？这主要是为了防止已失效的请求连接报文忽然又传送到了，从而产生错误。
假定A向B发送一个连接请求，由于一些原因，导致A发出的连接请求在一个网络节点逗留了比较多的时间。此时A会将此连接请求作为无效处理 又重新向B发起了一次新的连接请求，B正常收到此连接请求后建立了连接，数据传输完成后释放了连接。如果此时A发出的第一次请求又到达了B，B会以为A又发起了一次连接请求，如果是两次握手：此时连接就建立了，B会一直等待A发送数据，从而白白浪费B的资源。 如果是三次握手：由于A没有发起连接请求，也就不会理会B的连接响应，B没有收到A的确认连接，就会关闭掉本次连接。
在谢希仁著《计算机网络》第四版中讲“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”，书中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”而是“两次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。说白了主要目的是防止server端一直等待，浪费资源。
为什么TCP的挥手需要四次？
TCP是全双工的连接，必须两端同时关闭连接，连接才算真正关闭。
如果一方已经准备关闭写，但是它还可以读另一方发送的数据。发送给FIN结束报文给对方对方收到后，回复ACK报文。当这方也已经写完了准备关闭，发送FIN报文，对方回复ACK。两端都关闭，TCP连接正常关闭。
为什么A在TIME-WAIT状态必须等待2MSL的时间呢？
-
防止 客户端最后一段ACK报文丢失。如果最后一个ACK报文因为网络原因被丢弃，此时server因为没有收到ACK而超时重传FIN报文，处于TIME_WAIT状态的client可以继续对FIN报文做回复，向server发送ACK报文。
-
防止 已失效的连接请求报文段。保证让迟来的TCP报文段有足够的时间被识别和丢弃。连接结束了，网络中的延迟报文也应该被丢弃掉，以免影响立刻建立的新连接。
A在发送完ACK报文段后，再经过2MSL时间，就可以使本连接持续的时间所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求的报文段。
为什么是2MSL（报文最大生存时间）呢？
TIME_WAIT的状态是为了等待连接上所有的分组的消失。单纯的想法，发送端只需要等待一个MSL就足够了。这是不够的，假设现在一个MSL的时候，接收端需要发送一个应答，这时候，我们也必须等待这个应答的消失，这个应答的消失也是需要一个MSL，所以我们需要等待2MSL。
TCP和UDP的区别
-
TCP是有连接的，两台主机在进行数据交互之前必须先通过三次握手建立连接；而UDP是无连接的，没有建立连接这个过程
-
TCP是可靠的传输，TCP协议通过确认和重传机制来保证数据传输的可靠性；而UDP是不可靠的传输
-
TCP还提供了拥塞控制、滑动窗口等机制来保证传输的质量，而UDP都没有
-
TCP是基于字节流的，将数据看做无结构的字节流进行传输，当应用程序交给TCP的数据长度太长，超过MSS时，TCP就会对数据进行分段，因此TCP的数据是无边界的；而UDP是面向报文的，无论应用程序交给UDP层多长的报文，UDP都不会对数据报进行任何拆分等处理，因此UDP保留了应用层数据的边界
-
TCP首部开销(20个字节)比UDP的首部开销(8个字节)要大
-
TCP只支持点对点通信，UDP支持一对一、一对多、多对一、多对多的通信模式；
-
TCP怎么保证连接的唯一性
TCP怎么保证连接的唯一性（答案：TCP的源端口、目的端口、以及IP层的源IP地址、目的IP地址四元组唯一的标识了一个TCP连接）
TCP和UDP分别对应的常见应用层协议
(1). TCP 对应的应用层协议：
FTP：定义了文件传输协议，使用21端口。常说某某计算机开了FTP服务便是启动了文件传输服务。下载文件，上传主页，都要用到FTP服务。
Telnet：它是一种用于远程登陆的端口，用户可以以自己的身份远程连接到计算机上，通过这种端口可以提供一种基于DOS模式下的通信服务。如以前的BBS是-纯字符 界面的，支持BBS的服务器将23端口打开，对外提供服务。
SMTP：定义了简单邮件传送协议，现在很多邮件服务器都用的是这个协议，用于发送邮件。如常见的免费邮件服务中用的就是这个邮件服务端口，所以在电子邮件设置 中常看到有这么SMTP端口设置这个栏，服务器开放的是25号端口。
POP3：它是和SMTP对应，POP3用于接收邮件。通常情况下，POP3协议所用的是110端口。也是说，只要你有相应的使用POP3协议的程序（例如Fo-xmail或 Outlook），就可以不以Web方式登陆进邮箱界面，直接用邮件程序就可以收到邮件（如是163邮箱就没有必要先进入网易网站，再进入自己的邮-箱来收信）。
HTTP：从Web服务器传输超文本到本地浏览器的传送协议。
(2). UDP 对应的应用层协议：
DNS：用于域名解析服务，将域名地址转换为IP地址。DNS用的是53号端口。
SNMP：简单网络管理协议，使用161号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。
TFTP(Trival File Transfer Protocal)：简单文件传输协议，该协议在熟知端口69上使用UDP服务。
TCP如何保证可靠的传输?
https://www.cnblogs.com/deliver/p/5471231.html
1、确认和重传：接收方收到报文就会确认，发送方发送一段时间后没有收到确认就重传。
2、数据校验
3、数据合理分片和排序：
UDP：IP数据报大于1500字节,大于MTU.这个时候发送方IP层就需要分片(fragmentation).把数据报分成若干片,使每一片都小于MTU.而接收方IP层则需要进行数据报的重组.这样就会多做许多事情,而更严重的是,由于UDP的特性,当某一片数据传送中丢失时,接收方便无法重组数据报.将导致丢弃整个UDP数据报.
tcp会按MTU合理分片，接收方会缓存未按序到达的数据，重新排序后再交给应用层。
4、流量控制：当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。
5、拥塞控制：当网络拥塞时，减少数据的发送。
先回答如果传输不可靠，会出现什么问题。 如果解决以下问题传输就可靠了*
1.包中传输过程中出错了怎么办。
数据校验
2.包发送的太快，接收方有缓存满了处理不过来丢包。
流量控制
3.包在传输过程中丢了怎么办。
重传机制
4.发送端开始发送数据的时候，如果刚开始就发送大量的数据，那么就可能造成一些问题
拥塞机制
什么是CLOSE_WAIT状态?
CLOSE_WAIT：表示被动关闭方等待关闭。当收到对方调用close函数发送的FIN报文时，回应对方ACK报文，此时进入CLOSE_WAIT状态。
大家知道，由于socket是全双工的工作模式，一个socket的关闭，是需要四次握手来完成的。
1.主动关闭连接的一方，调用close()；协议层发送FIN包
2.被动关闭的一方收到FIN包后，协议层回复ACK；然后被动关闭的一方，进入CLOSE_WAIT状态，主动关闭的一方等待对方关闭，则进入FIN_WAIT_2状态；此时，主动关闭的一方 等待 被动关闭一方的应用程序，调用close操作
3.被动关闭的一方在完成所有数据发送后，调用close()操作；此时，协议层发送FIN包给主动关闭的一方，等待对方的ACK，被动关闭的一方进入LAST_ACK状态；
4.主动关闭的一方收到FIN包，协议层回复ACK；此时，主动关闭连接的一方，进入TIME_WAIT状态；而被动关闭的一方，进入CLOSED状态
5.等待2MSL时间，主动关闭的一方，结束TIME_WAIT，进入CLOSED状态
更详细的状态说明请参考：https://www.cnblogs.com/yorkyang/p/7657683.html
https://blog.csdn.net/enlaihe/article/details/78900482
time wait的缺点？
首先调用close()发起主动关闭的一方，在发送最后一个ACK之后会进入time_wait的状态，也就说该发送方会保持2MSL时间之后才会回到初始状态。MSL值得是数据包在网络中的最大生存时间。产生这种结果使得这个TCP连接在2MSL连接等待期间，定义这个连接的四元组（客户端IP地址和端口，服务端IP地址和端口号）不能被使用。
socket就是一个 五元组，包括：源IP,源端口,目的IP目,的端口,类型：TCP or UDP
长连接与短连接
短连接：例如普通的web请求，在三次握手之后建立连接，发送数据包并得到服务器返回的结果之后，通过客户端和服务端的四次握手进行关闭断开。
长连接：区别于短连接，由于三次握手链接及四次握手断开，在请求频繁的情况下，链接请求和断开请求的开销较大，影响效率。采用长连接方式，执行三次握手链接后，不断开链接，保持客户端和服务端通信，直到服务器超时自动断开链接，或者客户端主动断开链接。
适用场景：
短连接：适用于网页浏览等数据刷新频度较低的场景。
长连接：适用于客户端和服务端通信频繁的场景，例如聊天室，实时游戏等。
优点和缺点
（1）长连接，可以省去较多的tpc建立和关闭操作，减少资源的浪费，节约时间。长连接多用于操作频繁，点对点的通讯，而且连接数不能太多。数据库的连接就是使用长连接，如果用短连接频繁通讯会造成socket错误，而且频繁的Socket创建和销毁也是对资源的消耗比较大。
（2）短连接，短连接对于服务器来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段，web网站一般使用短连接，因为长连接对服务端来说会消耗一定资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的，对资源消耗过大
如发现系统存在大量TIME_WAIT状态的连接，通过调整内核参数解决，
vim /etc/sysctl.conf
编辑文件，加入以下内容：
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30然后执行 /sbin/sysctl -p 让参数生效。
net.ipv4.tcp_syncookies = 1 表示开启SYN cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。
net.ipv4.tcp_fin_timeout 修改系統默认的 TIMEOUT 时间
四次挥手—服务器先关闭，客户端不关闭，继续发送数据，会出现什么情况？
触发四次挥手机制：
服务器：发出FIN,客户端回复ACK，进入TIME_WAIT状态
客户端：没有close(),处于close_wait()状态，
接着向服务器继续发送数据，会出现什么情况？
客户端：因为对方关闭（相当于管道中对方的读端关闭写端写满缓冲区就会触发SIGPIPE信号，操作系统会强制关闭写端），客户端继续写的话，会触发SIGPIPE信号，操作系统会强制关闭客户端
为什么QQ用UDP，QQ如何保证信息传输安全的？
1.文件传输使用的是TCP。
2.因为有海量用户的数据需要并发，UDP速度快
3.传输的可靠性靠上层的协议来保证（如应用层）。发送失败则提示是否需要重新发送。
tcp为什么是可靠的？
确认和重传
数据校验
数据合理分片和排序
流量控制
拥塞控制（四种算法）
tcp，udp的应用场景。什么应用层协议会使用到他
TCP一般用于文件传输（FTP HTTP 对数据准确性要求高，速度可以相对慢），发送或接收邮件（POP IMAP SMTP 对数据准确性要求高，非紧急应用），远程登录（TELNET SSH 对数据准确性有一定要求，有连接的概念）等等；UDP一般用于即时通信（QQ聊天 对数据准确性和丢包要求比较低，但速度必须快），在线视频（RTSP 速度一定要快，保证视频连续，但是偶尔花了一个图像帧，人们还是能接受的），网络语音电话（VoIP 语音数据包一般比较小，需要高速发送，偶尔断音或串音也没有问题）等等。
多路复用技术
I/O多路复用，I/O就是指的我们网络I/O,多路指多个TCP连接(或多个Channel)，复用指复用一个或少量线程。
串起来理解就是很多个网络I/O复用一个或少量的线程来处理这些连接。
在同一个线程里面， 通过拨开关的方式，来同时传输多个I/O流， (学过EE的人现在可以站出来义正严辞说这个叫“时分复用”了）。
什么，你还没有搞懂“一个请求到来了，nginx使用epoll接收请求的过程是怎样的”， 多看看这个图就了解了。提醒下，ngnix会有很多链接进来， epoll会把他们都监视起来，然后像拨开关一样，谁有数据就拨向谁，然后调用相应的代码处理。
UDP如何保证顺序传播
UDP 是无顺序的，先发的包不一定会先到，所以最好还是自己在协议中增加包的编号。
接收处理时，按无序的逻辑进行，这样就能正常完成数据的接收。
否则，就换 TCP 协议吧，它的顺序是可以保证的。
TCP粘包现象
TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。
TCP默认会使用Nagle算法。而Nagle算法主要做两件事：
1）只有上一个分组得到确认，才会发送下一个分组；2）收集多个小分组，在一个确认到来时一起发送。
所以，正是Nagle算法造成了发送方有可能造成粘包现象。
在socket网络程序中，TCP和UDP分别是面向连接和非面向连接的。因此TCP的socket编程，收发两端（客户端和服务器端）都要有成对的socket，因此，发送端为了将多个发往接收端的包，更有效的发到对方，使用了优化方法（Nagle算法），将多次间隔较小、数据量小的数据，合并成一个大的数据块，然后进行封包。这样，接收端，就难于分辨出来了，必须提供科学的拆包机制。
对于UDP，不会使用块的合并优化算法，这样，实际上目前认为，是由于UDP支持的是一对多的模式，所以接收端的skbuff(套接字缓冲区）采用了链式结构来记录每一个到达的UDP包，在每个UDP包中就有了消息头（消息来源地址，端口等信息），这样，对于接收端来说，就容易进行区分处理了。所以UDP不会出现粘包问题。
为了避免粘包现象，可采取以下几种措施：
（1）对于发送方引起的粘包现象，用户可通过编程设置来避免，TCP提供了强制数据立即传送的操作指令push，TCP软件收到该操作指令后，就立即将本段数据发送出去，而不必等待发送缓冲区满；
（2）对于接收方引起的粘包，则可通过优化程序设计、精简接收进程工作量、提高接收进程优先级等措施，使其及时接收数据，从而尽量避免出现粘包现象；
（3）由接收方控制，将一包数据按结构字段，人为控制分多次接收，然后合并，通过这种手段来避免粘包。
P不会出现粘包问题。
如何保证UDP可靠的传输
https://www.jianshu.com/p/6c73a4585eba
可靠用户数据报协议（RUDP）基于UDP的数据传输协议（UDT） 实时控制协议（RTCP） 实时传输协议（RTP）
RTP实行有序传送,但并不保证传送或防止无序传送
客户端网忽然断了，TCP什么情况
如果网线断开的时间短暂，在SO_KEEPALIVE设定的探测时间间隔内，并且两端在此期间没有任何针对此长连接的网络操作。当连上网线后此TCP连接可以自动恢复，继续进行正常的网络操作。
如果网线断开的时间很长，超出了SO_KEEPALIVE设定的探测时间间隔，或者两端期间在此有了任何针对此长连接的网络操作。当连上网线时就会出现ETIMEDOUT或者ECONNRESET的错误。你必须重新建立一个新的长连接进行网络操作。
udp的connect
-
UDP中可以使用connect系统调用
-
UDP中connect操作与TCP中connect操作有着本质区别.TCP中调用connect会引起三次握手,client与server建立连结.UDP中调用connect内核仅仅把对端ip&port记录下来.
-
UDP中可以多次调用connect,TCP只能调用一次connect.UDP多次调用connect有两种用途:1,指定一个新的ip&port连结.2,断开和之前的ip&port的连结.指定新连结,直接设置connect第二个参数即可.断开连结,需要将connect第二个参数中的sin_family设置成 AF_UNSPEC即可.
-
UDP中使用connect可以提高效率.原因如下:普通的UDP发送两个报文内核做了如下:#1:建立连结#2:发送报文#3:断开连结#4:建立连结#5:发送报文#6:断开连结
采用connect方式的UDP发送两个报文内核如下处理:#1:建立连结#2:发送报文#3:发送报文另外一点,每次发送报文内核都由可能要做路由查询.
服务器中含有大量一直处于close_wait的tcp连接，是为什么？
-
程序Bug，接收到FIN信号后没有及时关闭socket，这可能是Netty的Bug，也可能是业务层Bug；
-
关闭socket不及时：例如I/O线程被意外阻塞，或者I/O线程执行的用户自定义Task比例过高，导致I/O操作处理不及时，链路不能被及时释放。
因服务器发生了socket未关导致的closed_wait发生，致使监听port打开的句柄数到了1024个，且均处于close_wait的状态，最终造成配置的port被占满出现“Too many open files”，无法再进行通信。
close_wait状态出现的原因是被动关闭方未关闭socket造成，导致下一个socket，无法正常接收。
心跳机制
心跳机制是TCP在一段时间间隔后发送确定连接端是否还存在，如果存在的话就会回传一个包确定网络有效，如果心跳包有问题，则通知上层应用当前网络有问题了。
tcp校验和
三次握手的第三个ACK包丢了，TCP的处理方式
当Client端收到Server的SYN+ACK应答后，其状态变为ESTABLISHED，并发送ACK包给Server；
如果此时ACK在网络中丢失，那么Server端该TCP连接的状态为SYN_RECV，并且依次等待3秒、6秒、12秒后重新发送SYN+ACK包，以便Client重新发送ACK包。
Server重发SYN+ACK包的次数，可以通过设置/proc/sys/net/ipv4/tcp_synack_retries修改，默认值为5。
如果重发指定次数后，仍然未收到ACK应答，那么一段时间后，Server自动关闭这个连接。
但是Client认为这个连接已经建立，如果Client端向Server写数据，Server端将以RST包响应，方能感知到Server的错误
ARP协议
地址解析协议，即ARP（Address Resolution Protocol），是根据IP地址获取物理地址的一个TCP/IP协议。主机发送信息时将包含目标IP地址的ARP请求广播到网络上的所有主机，并接收返回消息，以此确定目标的物理地址。属于链路层协议。
而DNS则是典型的应用层的协议了