1.TCP&UDP
1.1TCP与UDP的区别
TCP传输数据稳定可靠，适用于对网络通信质量要求较高的场景。
面向连接。
每一条TCP有且只有两个端点，为一对一关系。
提供可靠交付。
全双工通信，全双工为即可传输又可接收。
面向字节流。
UDP的优点是速度快，但是可能会产生丢包，所以适用于对实时性要求较高，但是对少量丢包没有太大要求的场景
无连接，发送数据之前不需要建立连接。
尽最大努力交付，不保证可靠交付，不使用拥塞控制。
面向报文，适合多媒体通信。
支持一对一，一对多，多对一，多对多的交互通信。
首部开销小，8个字节。
1.2tcp拥塞控制
慢开始
假设当前发送方拥塞窗口cwnd的值为1，而发送窗口swnd等于拥塞窗口cwnd，因此发送方当前只能发送一个数据报文段（拥塞窗口cwnd的值是几，就能发送几个数据报文段），接收方收到该数据报文段后，给发送方回复一个确认报文段，发送方收到该确认报文后，将拥塞窗口的值变为2。即收到多少确认报文就增加多少。所以拥塞窗口是以指数型增长的（1,2,4,8...）。一直到cwnd等于ssthresh阈值时启动拥塞控制算法。
拥塞避免
进入拥塞避免阶段时，cwnd每次只能加1。当出现报文丢失时，丢失的报文的重传计时器超时后会被判断出现拥塞，此时需要更改cwnd和ssthresh。
出现拥塞：
1、ssthresh更新为出现拥塞时cwnd数值的一半；
2、cwnd赋值为1；
3、重新执行慢开始算法。
快速重传
发送方一旦收到3个连续的重复确认报文，就将相应的报文段立即重传，而不是等该报文段的超时重传计时器超时再重传。
快速恢复
发送端连续接收端三个重复确认报文 后可以确认只是丢失了个别报文（确认报文可以传回，网络没有拥塞 ），此时不需要启动慢开始算法。此时将ssthresh和cwnd赋值为此时的cwnd的一半，然后执行拥塞避免算法。
1.3tcp连接中断的原因
网络中间节点和客户端 / 服务器节点参与通信的两方节点？
中间节点：路由器，防火墙，网关
1.4TCP传输过程中故障问题
- 服务器主机崩溃
客户端在给服务器发送数据时，由于收不到服务器端回传的ACK确认报文，正常情况下，客户端TCP均会进行超时重传，一般为重传12次大约9分钟后才放弃重传，并关闭客户端TCP链接。
- 服务器主机崩溃后重启
如果服务器主机在崩溃重启的这段时间里，客户端没有向服务器发送数据，即客户端没有因重传次数超过限制关闭TCP链接。则在服务器重启后，当客户端再向服务器发送TCP报文时，由于服务器中的TCP链接已经关闭，会直接向客户端回复RST报文，客户端在接收RST报文后关闭自己的TCP链接。
- 服务器主机断网或者中间路由器出现故障
与情况1类似，客户端会进行超时重传，直到重传次数超过后放弃重传，并关闭客户端TCP链接。(因为TCP中会忽略目的主机不可达和目的网络不可达的ICMP报文，并进行重传，直到重传总时间超过限制)
- 服务器主机断网或者中间路由器出现故障后又恢复
如果在服务器主机断网或者中间路由器出现故障这段时间内，客户端和服务器之间没有进行相互通信，即双方均没有察觉对方目的不可达，则在恢复网络链接后两端的TCP链接均有效，能够正常继续进行通信。
如果在服务器主机断网或者中间路由器出现故障这段时间内，客户端因向服务器发送数据超时，并重传总时间超过限制关闭TCP链接。则再网络恢复后，服务器再向客户端发送TCP报文时，客户端也会直接恢复RST报文，服务器再收到RST报文后关闭自己的TCP链接。
- 服务器关机或服务器进程被终止
正常情况下服务器主机被关机时，操作系统都会事先通知所有仍在运行的进程，并先将所有进程终止后，再继续关闭电脑。而所有的进程在被终止时，Unix操作系统内核都会事先去关闭所有已经打开的TCP链接，即向客户端发生FIN标志报文，进行四次握手关闭连接。
因此，对于这种情况，客户端是能够察觉到并正常关闭TCP链接。
- 服务器的端口被关闭
如果在通信过程中，服务器的监听端口被管理员或系统禁掉，则当客户端再向服务器发送TCP报文时，服务器在收到该报文后，由于发送该目的端口没有处于监听状态，则会直接向客户端发送RST报文，客户端在收到RST报文后会直接关闭自己TCP链接。
1.5TCP流量控制
首先要明白一点，应用程序不论发送还是接收数据，都会先把数据放入缓冲区，再从缓冲区中发出或读取数据。就像秘书，先把事情整理归纳好，再一次性向你汇报。
这个缓冲区大小，反映了应用程序一次能处理数据的能力。如果接收方应用程序处理速度比发送方的发送速度慢，就会造成接收方缓冲区"溢出"。实际上，发送方发送速度和接收方处理速度很难一致。
TCP在三次握手建立连接时，会协商双方缓冲区window大小。如果因为接收方处理速度较慢，接收方会通过window告知发送方，实现动态调整，避免"溢出"。
TCP滑动窗口分为接受窗口，发送窗口
滑动窗口协议是传输层进行流控的一种措施，接收方通过通告发送方自己的窗口大小，从而控制发送方的发送速度，从而达到防止发送方发送速度过快而导致自己被淹没的目的。
对ACK的再认识，ack通常被理解为收到数据后给出的一个确认ACK，ACK包含两个非常重要的信息：
**一是期望接收到的下一字节的序号n，该n代表接收方已经接收到了前n-1字节数据，此时如果接收方收到第n+1字节数据而不是第n字节数据，****接收方是不会发送序号为n+2的ACK的。**举个例子，假如接收端收到1-1024字节，它会发送一个确认号为1025的ACK,但是接下来收到的是2049-3072，它是不会发送确认号为3072的ACK,而依旧发送1025的ACK。
二是当前的窗口大小m，如此发送方在接收到ACK包含的这两个数据后就可以计算出还可以发送多少字节的数据给对方，假定当前发送方已发送到第x字节，则可以发送的字节数就是y=m-(x-n).这就是滑动窗口控制流量的基本原理
重点：发送方根据收到ACK当中的期望收到的下一个字节的序号n以及窗口m，还有当前已经发送的字节序号x，算出还可以发送的字节数。
1.6TCP三次握手
简述三次握手
第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手
1.7TCP四次挥手
1.7.1四次挥手过程
在断开连接之前客户端和服务器都处于ESTABLISHED状态，双方都可以主动断开连接，以客户端主动断开连接为优。
第一次挥手：客户端打算断开连接，向服务器发送FIN报文，之后客户端进入FIN_WAIT_1状态。
第二次挥手：服务器收到连接释放报文段(FIN报文)后，就向客户端发送ACK应答报文
接着服务器进入CLOSE_WAIT(等待关闭)状态，此时的TCP处于半关闭状态(下面会说什么是半关闭状态)，客户端到服务器的连接释放。客户端收到来自服务器的ACK应答报文段后，进入FIN_WAIT_2状态。
第三次握手：服务器也打算断开连接，向客户端发送连接释放(FIN)报文段，之后服务器进入LASK_ACK(最后确认)状态，等待客户端的确认。
第四次握手：客户端收到来自服务器的连接释放(FIN)报文段后，会向服务器发送一个ACK应答报文段
之后客户端进入TIME_WAIT(时间等待)状态，服务器收到ACK应答报文段后，服务器就进入CLOSE(关闭)状态，到此服务器的连接已经完成关闭。
客户端处于TIME_WAIT状态时，此时的TCP还未释放掉，需要等待2MSL后，客户端才进入CLOSE状态。
由客户端到服务器需要一个FIN和ACK，再由服务器到客户端需要一个FIN和ACK，因此通常被称为四次握手。
客户端和服务器都可以主动关闭连接，只有率先请求关闭的一方才会进入TIME_WAIT(时间等待状态)。
1.7.2为什么挥手需要四次？
这是由于TCP的半关闭(half-close)造成的。半关闭是指：TCP提供了连接的一方在结束它的发送后还能接受来自另一端数据的能力。通俗来说，就是不能发送数据，但是还可以接受数据。
TCP不允许连接处于半打开状态时，就单向传输数据，因此完成三次握手后才可以传输数据(第三握手可以携带数据)。
当连接处于半关闭状态时，TCP是允许单向传输数据的，也就是说服务器此时仍然可以向客户端发送数据，等服务器不再发送数据时，才会发送FIN报文段，同意现在关闭连接。
这一特性是由于TCP双向通道互相独立所导致的，也使得关闭连接必须经过四次握手。
1.7.3等待2MSL的意义
1.保证客户端最后发送的ACK能够到达服务器，帮助其正常关闭。
由于这个ACK报文段可能会丢失，使得处于LAST_ACK状态的服务器得不到对已发送FIN报文段的确认，从而会触发超时重传。服务器会重发FIN报文段，客户端能保证在2MSL时间内收到来自服务器的重传FIN报文段，从而客户端重新发送ACK应答报文段，并重置2MSL计数。
假如客户端不等待2MSL就之间进入CLOSE状态，那么服务器会一直处于LAST_ACK状态。
当客户端发起建立SYN报文段请求建立新的连接时，服务端会发送RST报文段给客户端，连接建立的过程就会被终止。
2.防止已失效的连接请求报文段出现在本连接中。
TIME_WAIT等待的2MSL时间，确保本连接内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。
1.8TCP/UDP如何解决丢包问题？
1.8.1TPC为什么会丢包？
-
TCP是基于不可靠的网路实现可靠传输，肯定会存在丢包问题。
-
如果在通信过程中，发现缺少数据或者丢包，那边么最大的可能性是程序发送过程或者接受过程中出现问题。
1.8.2如何解决TCP丢包的问题
为了满足TCP协议不丢包。TCP协议有如下规定：
数据分片：发送端对数据进行分片，接受端要对数据进行重组，由TCP确定分片的大小并控 制分片和重组
到达确认：接收端接收到分片数据时，根据分片数据序号向发送端发送一个确认
超时重发：发送方在发送分片时设置超时定时器，如果在定时器超时之后没有收到相应的确 认，重发分片数据
滑动窗口：TCP连接的每一方的接受缓冲空间大小固定，接收端只允许另一端发送接收端缓冲区所能接纳的数据，TCP在滑动窗口的基础上提供流量控制，防止较快主机致使较慢主机的缓冲区溢出
失序处理：作为IP数据报来传输的TCP分片到达时可能会失序，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层;
重复处理：作为IP数据报来传输的TCP分片会发生重复，TCP的接收端必须丢弃重复的数据;
数据校验：TCP将保持它首部和数据的检验和，这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到分片的检验或有差错，TCP将丢弃这个分片，并不确认收到此报文段导致对端超时并重发
2.计算机网络分层体系结构（五层举例）
应用层 ：为应用程序提供交互服务。在互联网中的应用层协议很多，如域名系统DNS、HTTP协议、SMTP协议等。
传输层 ：负责向两台主机进程之间的通信提供数据传输服务。传输层的协议主要有传输控制协议TCP和用户数据协议UDP。
网络层 ：选择合适的路由和交换结点，确保数据及时传送。主要包括IP协议。
数据链路层 ：在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。
物理层：实现相邻节点间比特流的透明传输，尽可能屏蔽传输介质和物理设备的差异。
3.HTTP和HTTPS区别
HTTP:是互联网上应用最为广泛的一种网络通信协议，基于TCP，可以使浏览器工作更为高效，减少网络传输。
HTTPS:是HTTP的加强版，可以认为是HTTP+SSL(Secure Socket Layer)。在HTTP的基础上增加了一系列的安全机制。一方面保证数据传输安全，另一位方面对访问者增加了验证机制。是目前现行架构下，最为安全的解决方案。
1.http 协议是免费使用的，而 https 协议需要到CA机构申请证书，需要缴纳费用
2.http 是超文本传输协议，信息是明文传输，https 则是具有安全性的 ssl/tls 加密传输协议，信息是密文
3.http 的连接很简单，是无状态的；https 协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议，比 http 协议安全
4.和 http 通信相比，https 通信会由于加减密处理消耗更多的CPU和内存资源
5.http 和 https 使用的端口也不一样，前者是80，后者是443