TCP和UDP的区别
TCP和UDP的5点区别：
- TCP是面向连接的而UDP是无连接的。TCP进行数据传输时，需要通过三次握手建立一条TCP传输连接，传输完成后通过四次挥手释放连接；而UDP在传输过程中不需要在通信双方之间建立连接，可以直接进行数据传输。
- TCP可以保证数据可靠性，UDP可能会丢包。因为TCP是通过建立连接来传送数据，协议里面有校验和、重传控制、确认应答等机制来保证数据的可靠性；UDP协议是尽最大努力交付，不保证可靠交付，除了提供一种可选的检验和，几乎没有提供其他的机制来保证数据传输可靠性，如果检测出收到的分组出错，则丢弃这个分组，既不确认，也不通知发送端和要求重传
- TCP传输速度慢，UDP传输速度快。TCP每发一次报文都需要确认应答，若超时未收到确定会重新再发一次报文；UDP没有这种机制，一个个数据包不断地发送，即使数据包是错的也直接丢弃该数据包。
- TCP是面向字节流，而UDP是面向报文的。TCP将数据看成是一连串的、无结构的字节流，在发送端和接收端都会维护一个缓存对数据进行粘包和拆包，将几个字节流组成一个报文进行发送；UDP对应用程序提交的报文既不合并，也不拆分，保留原报文的长度和格式，原封不动地发送出去。
- TCP连接只能是点到点的，但支持同时建立多个并发的TCP连接，而UDP支持一对一，一对多，多对一和多对多的交互通信
应用场景：
注：说完区别之后，可以随便总结一下，说下两者的常用应用场景。
- TCP注重的是可靠性，而不是实时性，具有一定的延迟性。常用于对数据准确性要求高的应用场景。例如文件传输、邮件的发送与接收等。
- UDP注重的是实时性，速度快，可靠性不高。常用于对数据安全无特速要求的应用场景。例如IP电话、实时视频会议等。
- 对于特别的场合，可以对UDP协议基础上再进行封装，UDP协议适用于（1）视频播放应用，（2）简短的交互式应用，（3）多播和广播应用。
哪些典型的应用用的是UDP协议
- 流媒体，比如直播
- 实时游戏
- 物联网
- QQ文件传输、QQ语音、QQ视频
TCP的三次握手和四次挥手?
三次握手
三次握手的过程：
- 客户端向服务端发送一个同步序号SYN=1，序列号Seq=x（x是随机产生的，且不能为0）的请求报文；
- 服务器收到消息之后返回确认报文来通知客户端已经收到了请求报文并通过了确认，报文内容的确认序号标志ACK=1，确认号ack是客户端报文中序列号seq数值+1，同步序号SYN=1，序列号seq=Y；
- 客户端收到确认报文后，此时客户端发向服务端的通道连接建立成功，然后客户端需要发送确认报文给服务端，报文内容的确认序号标志ACK=1，序列号Seq=x+1和确认号ack=y+1
- 服务端收到ack报文后，此时服务端发向客户端的通道连接建立成功，TCP的全双工连接建立完毕
为啥要三次握手？两次不可以吗？
TCP的连接是全双工的，TCP协议通信的双方，都维护着有一个初始序列号，以标识发送出去，然后需要得到确认才可以建立起双方的连接通道， 如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方序列号则得不到确认，无法达成一致。
三次握手失败了怎么办？
TCP在建立的过程中，如果一直等待不到确认信息，会进行重传，不断尝试，直到超时时间达到最大上限，就会放弃连接。
三次握手的状态转换？
- 客户端：CLOSED =》发送Syn 消息 =》SYN_SENT=》收到Server端发回的SYN+ACK =》ESTABLISHED =》 发送和接收数据 =》发送FIN =》FIN_WAIT_1 =》接受确认，不发送任何信息 =》FIN_WAIT_2 =》接收FIN，发送ACK =》TIME_WAIT =》等待30秒 =》CLOSED
- 服务端：CLOSED =》服务器应用程序创建一个侦听套接字=》LISTEN=》接收SYN，发送SYN和ACK=》SYN_RCVD=》接收ACK，不发送任何信息 =》ESTABLISHED=》发送和接收数据=》接收FIN，发送ACK =》 CLOSE_WAIT =》发送FIN=》LAST_ACK =》接收ACK，不发送任何信息 =》CLOSED
四次挥手
客户端和服务器端都可以主动提出释放请求，一般是客户端主动提出释放请求
四次挥手的过程：
- 当客户端主动释放TCP连接时，停止发送数据，向服务器端发送控制位FIN=1，序列号seq=u（u等于客户端发送的最后一个字节的序号加1）的请求报文
- 服务器端接收到请求报文后，向客户端发送确认序号标志ACK=1，确认号ack=u+1，序列号seq=v（v等于服务器发送的最后一个字节序号加1）的确认报文
- 当服务器端数据都发送完毕后，服务器会向客户端发送控制位FIN=1，确认序号标志ACK=1，序列号=w（w取决于在“半关闭”状态，服务器是否发送过数据报文），确认号ack=u+1的请求报文
- 客户端在接收到请求报文后，向服务器发送确认序号标志ACK=1，序列号seq=u+1，确认号ack=w+1的确认报文，TCP连接释放完毕。
为什么要四次挥手？三次挥手不行吗？
TCP连接是全双工，服务器端接收到FIN说明客户端没有数据再发送过来，此时客户端处于半关闭状态。但服务器端自己还可以发送数据或还有数据没发完。前两次只是确认了关闭一个方向的数据，再加上后两次挥手才真正关闭整个TCP连接
为什么连接的时候是三次握手，关闭的时候却是四次握手？
因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步挥手
TIME_WAIT状态
- TIME_WAIT状态是主动关闭TCP连接的一方（即先发起FIN包的一方，一般是指客户端），在发送完最后一个ACK包后进入的状态，系统需要在TIME_WAIT状态下等待2MSL后才能释放连接（端口），一般的TCP实现有30秒、1分钟和2分钟不等。
- 进入TIME_WAIT状态等待2MSL主要有两个目的：
- 保证客户端发送的最后一个ACK能达到服务端，如果服务端没有收到最后一个ACK包时，会重传FIN+ACK报文段（客户端收到两个FIN的时间间隔一定小于2MSL）客户端收到重传后进行补发ACK，然后刷新2MSL计时器，从而保证服务端能正常进入CLOSED状态。
- 处于TIME_WAIT的连接（IP和端口组合）不能重用，这样可以保证被重新分配的socket不会受到之前残留的延迟重发报文影响
什么时候会服务器会进行主动关闭的情况？
一般来说，都是客户端发起的关闭请求，如果是服务端主动发起关闭，四次挥手的顺序会颠倒，那么此时客户端再向服务端发送数据时，根据TCP协议的规定，认为它是一个异常终止连接，客户端将会收到一个RST复位响应(而不是ACK响应)，如果客户端再次向服务端发送数据，系统将会发送一个SIGPIPE信号给客户端进程，告诉客户端进程该连接已关闭，不要再写了。系统给SIGPIPE信号的默认处理是直接终止收到该信号的进程，所以此时客户端进程会被极不情愿地终止。
在HTTP/0.9协议中，只有短连接，服务器关闭表示数据发送完毕，所以服务器主动关闭属于历史的遗留问题。其次就是服务端资源不足，主动关闭连接。
如何避免TIME_WAIT状态
首先服务器可以设置SO_REUSEADDR套接字选项来通知内核，如果端口忙，但TCP连接位于TIME_WAIT状态时可以重用端口。在一个非常有用的场景就是，如果你的服务器程序停止后想立即重启，而新的套接字依旧希望使用同一端口，此时SO_REUSEADDR选项就可以避免TIME_WAIT状态。
TIME_WAIT多了有什么问题？
TIME_WAIT被占用的是一个五元组(协议,本地IP,本地端口,远程IP,远程端口)。对于Web服务器，协议是TCP,本地ip也只有一个,端口一般是80或者433或8080(固定的)，只剩下远程IP和远程端口可用了,如果远程IP相同的话，就只有远程端口可用了，远程端口只有几万个,所以当同一客户端向服务器建立了大量连接的话，可用的五元组会耗尽导致问题
HTTP的状态码
HTTP状态码是由三个十进制数字组成。第一个十进制数字定义了状态码的类型，后两个数字没有分类的作用，HTTP状态码可以分为5种类型：
- 1××：信息，服务器收到请求，需要请求者继续执行操作；
- 2××：成功，操作被成功接收并处理；
- 3××：重定向，需要进一步的操作以完成请求；
- 4××：客户端错误，请求包含语法错误或无法完成请求；
- 5××：服务器错误，服务器在处理请求的过程中发生了错误。
在实际开发中，常用的HTTP状态码是200：请求成功；301：资源被永久转移到其他URL；404：请求的资源不存在；500：内部服务器错误。
TCP/IP协议是如何保证消息可靠传输的
- TCP协议保证数据传输可靠性的方式主要有：（1）连接管理机制（2）序列号（3）确认应答机制（4）超时重传机制（5）检验和（6）流量控制（7）拥塞控制
- 连接管理机制：TCP建立连接的时候，需要通过三次握手来建立起双工管道的链接，释放链接的时候，需要通过四次挥手来释放链接；
- 序列号：TCP会对发送的每个报文进行编号，来保证数据可以按序到达
- 确认应答机制：在数据传输的过程中，接收方必须对每个报文进行确认应答，如果等待一定时间没收到确认，那么就会重传这个报文
- 超时重传机制：如果数据发出后一定时间没收到确认，那么发送方就会重发，如果接收方收到重复的数据，就会将其丢弃，然后重新发送ack确认报文
- 检验和：TCP 会计算数据包的校验和，保存在校验和字段和数据一起发送出去，而接收方会对报文进行校验，如果有差错，那么就丢弃这个报文段和不发送确认字段等待重传
- 流量控制：TCP报文中有个16位窗口字段，当接收方收到发送方的数据后，会在应答报文中将自身缓存区剩余大小放置窗口字段中，通知发送方下次可以接受数据的大小，来实现流量控制。如果缓冲区满，就将窗口置为0，发送方收到后就不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。注意：窗口大小不受16位窗口大小限制，在TCP首部40字节选项中还包含一个窗口扩大因子M，实际窗口大小是窗口字段的值左移M位
- 拥塞控制：当网络拥塞时，减少数据的发送。
TCP 中常见的拥塞控制算法有哪些？
为了进行拥塞控制，TCP 发送方要维持一个拥塞窗口(cwnd)的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。TCP的拥塞控制采用了四种算法，即慢开始、拥塞避免、快重传和快恢复
- 慢开始：如果开始发送数据时，立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。所以较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd初始值为1，每经过一个传播轮次，cwnd加倍。
- 拥塞避免：让拥塞窗口cwnd缓慢增大，即每经过一个往返时间RTT就把发送放的cwnd加1.
- 快重传：如果接收方收到一个失序的报文段就立即发出重复确认，当发送方一连收到三个重复确认的时候，就会立即重传尚未收到的报文段，而不必要等待设置的重传计时器时间到期。
- 快恢复：当发送方连续收到三个重复确认时，就会将慢开始门限减半，但是接下去并不执行慢开始算法，因为考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是执行拥塞避免算法
HTTP 与 HTTPS 有哪些区别？
HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全，而HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，Https协议使用需要申请证书
简述 HTTP 1.0，1.1，2.0 的主要区别？
- http1.0：每次请求都需要与服务器建立tcp连接，服务器处理完成后立即断开tcp连接
- http1.1：支持持久连接，避免了连接建立和释放的开销，但服务器必须按照客户端请求的先后顺序依次回送相应的结果，以保证客户端能够区分出每次请求的响应内容。通过Content-Length字段来判断当前请求的数据是否已经全部接收。不允许同时存在两个并行的响应
- http2.0：引入二进制数据格式，实现连接共享的多路复用，不同的请求可以使用同个连接进行传输
从输入 URL 到展现页面的全过程
DNS解析-> TCP连接->HTTP请求->浏览器解析渲染页面
- DNS解析
- DNS解析就是将域名转换为IP地址的转换
- 当我们在浏览器输入域名的时候，首先会从自己本地的hosts文件中是否有这个网址的映射关系；
- 如果没有的话，会查找本地的DNS解析器缓存，是否有这个网址的映射关系；
- 如果都没有的话，就会找在TCP/IP参数中设置的本地DNS服务器进行查找，服务器收到查询后，如果在本地配置中或者缓存解析中可以找到，则返回给客户端；
- 如果没有的话，本地DNS服务器会向根服务器进行查找。DNS的解析方式有两种，递归查询和迭代查询
- 递归查询：本地DNS服务器将请求转发至上一级DNS服务器，由上一级的DNS服务器进行解析，如果上级服务器解析不了，则上一级服务器继续向上转发请求，以此循环，知道最后查询结果返回客户端
- 迭代查询：如果DNS服务器查不到相应的记录，那么就想客户端返回一个可能知道结果的域名服务器ip，由客户端继续向新的服务器发送查询请求
- 最后将查找的结果返回给客户端，由客户端发送http请求
- TCP连接：TCP三次握手协议建立双工通道
- HTTP请求：客户端向服务器发起HTTP请求，服务器处理请求后返回http报文
- 浏览器解析渲染页面：在浏览器还没有完全接收HTML文件时便开始渲染、显示网页；在执行 HTML 中代码时，根据需要，浏览器会继续请求图片、CSS、JavsScript等文件，过程同请求 HTML ；
网络体系结构（OSI七层网络模型）
| OSI七层网络模型 | TCP/IP四层概念模型 | 对应网络协议 |
| 应用层 | 应用层 | HTTP、FTP、SMTP、NFS |
| 表示层 | Telnet、SNMP | |
| 会话层 | SMTP、DNS | |
| 传输层 | 传输层 | TCP、UDP |
| 网络层 | 互联网络层 | IP、ICMP、ARP、RARP、IGMP |
| 数据链路层 | 主机-网络层 | 底层网络定义的协议 |
| 物理层 |
- 物理层：传输单元是比特。利用传输介质为通信的主机之间建立、管理和释放物理连接，实现比特流的透明传输，为数据链路层提供数据传输服务
- 数据链路层：传输单元是帧。数据链路层在物理层提供比特流传输的基础上，通过建立数据链路连接，采用差错控制和流量控制方法，使有差错的物理线路变成无差错的数据链路
- 网络层：传输单元是分组。网络层通过路由选择算法为分组通过通信子网选择适当的传输路径，实现流量控制、拥塞控制与网络互联的功能
- 传输层：传输单元是报文。传输层向高层屏蔽了底层数据通信的细节，传输层为分布在不同地理位置计算机的进程通信提供可靠的端-端连接与数据传输服务
- 会话层：会话层负责维护两个会话主机之间连接的建立、管理和终止，以及数据的交换
- 表示层：表示层负责通信系统之间的数据格式变换、数据加密与解密、数据压缩与恢复
- 应用层：应用层实现协同工作的应用程序之间的通信过程控制
简述对称与非对称加密的概念？
所谓对称和非对称，是指的加密与解密的操作是否存在对称性。在对称加密中，加密与解密涉及到的是同一个工具（密钥），这样虽然方便，但万一这个工具被别人知道，通信就不再安全。非对称加密中，加密解密用的是不同的工具，即公钥和私钥，公钥用来加密，私钥用来解密，公钥和私钥是配对的。
例如：A有一个公钥A和一个私钥A，B有一个公钥B和私钥B，A,B通信时都会先将自己的公钥让对方知道，接下来，A发送信息给B时，先用公钥B给信息加密，这样B就可以在收到信息后用自己的私钥B解密，B给A发送信息时也是如此。注意，公钥私钥是严格配对的，A用公钥B加密后发给B的信息连A自己也无法解密，因为A没有B的私钥，私钥和公钥也几乎不可能通过数学方法相互推导得出
HTTP 的方法有哪些？
| 序号 | 方法 | 描述 |
|---|---|---|
| 1 | GET | 请求指定的页面信息，并返回实体主体。 |
| 2 | HEAD | 类似于 GET 请求，只不过返回的响应中没有具体的内容，用于获取报头 |
| 3 | POST | 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。 |
| 4 | PUT | 从客户端向服务器传送的数据取代指定的文档的内容。 |
| 5 | DELETE | 请求服务器删除指定的页面。 |
| 6 | CONNECT | HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。 |
| 7 | OPTIONS | 允许客户端查看服务器的性能。 |
| 8 | TRACE | 回显服务器收到的请求，主要用于测试或诊断。 |
| 9 | PATCH | 是对 PUT 方法的补充，用来对已知资源进行局部更新 。 |
Cookie 和 Session 的关系和区别是什么？
- Cookie 在客户端（浏览器），Session 在服务器端
- Cookie的安全性一般，可以通过分析存放在本地的Cookie并进行Cookie欺骗。在安全性第一的前提下，选择Session更优。重要交互信息比如权限等就要放在Session中，一般的信息记录放Cookie就好了
- 单个Cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个Cookie
- Session 可以放在 文件、数据库或内存中，比如在使用Node时将Session保存在redis中。由于一定时间内它是保存在服务器上的，当访问增多时，会较大地占用服务器的性能。考虑到减轻服务器性能方面，应当适时使用Cookie
- Session 的运行依赖Session ID，而 Session ID 是存在 Cookie 中的，也就是说，如果浏览器禁用了 Cookie，Session 也会失效（但是可以通过其它方式实现，比如在 url 中传递 Session ID）
- 用户验证这种场合一般会用 Session。因此，维持一个会话的核心就是客户端的唯一标识，即Session ID
什么是跨域，什么情况下会发生跨域请求？
- 浏览器从一个域名的网页去请求另一个域名的资源时，域名、端口、协议任一不同，都是跨域。它是由浏览器的同源策略造成的，是浏览器施加的安全限制
- 解决方法
- SpringBoot的注解@CrossOrigin（也支持SpringMVC）
- 增加一个配置类，处理跨域请求的Configuration
- 采用过滤器（filter）的方式，增加一个CORSFilter 类，并实现Filter接口即可，其他都不用管，接口调用时，会过滤跨域的拦截
什么是 TCP 粘包和拆包？
- TCP底层并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行包的划分，所以在业务上认为，一个完整的包可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的TCP粘包和拆包问题。
- 沾包和拆包的原因：要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包；接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包；要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包；待发送数据大于MSS（最大报文长度），TCP在传输前将进行拆包。即TCP报文长度-TCP头部长度>MSS。
- 带来的影响：一包数据内容被分在了两个连续的接收包中，处理起来难度较大；对于有结构的数据，沾包可能会改变其结构
- 粘包和拆包解决策略：这个问题只能通过上层的应用协议栈设计来解决
- 消息定长。发送端将每个数据包封装为固定长度（不够的可以通过补0填充），这样接收端每次接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来。
- 设置消息边界。服务端从网络流中按消息边界分离出消息内容。在包尾增加回车换行符进行分割，例如FTP协议。
- 将消息分为消息头和消息体，消息头中包含表示消息总长度（或者消息体长度）的字段。
- 更复杂的应用层协议。
以上资源都是来源各个网站的收集，然后对其整理，只是纯粹的八股文，如有雷同，纯属抄袭。
1083
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
