🤨运输层

TCP粘包，拆包及解决方法

TCP和UDP的区别？
- TCP是面向连接的，可靠的，支持点对点，一对一通信，面向字节流的，具有拥塞控制的传输层协议。
- UDP是无连接的，不可靠的，支持一对一，一对多，多对一，多对多通信，面向报文的，没有拥塞控制，适合媒体传输的传输协议。
计算机网络的核心思想？
- 分层、点对点、端对端
超大概率谈一下TCP 三次握手和四次挥手的理解？
- 三次握手
  - 第一次：在打算建立tcp连接时，客户端向服务器发送连接请求报文段，SYN置为1，同时选择一个初始序号seq = x。发送后，客户进程进入SYN-SENT（同步已发送）状态。
  - 第二次：服务器收到连接请求报文段后，如果同意建立连接，则向客户端发送确认。在确认报文段把SYN和ACK均置为1，确认后ack=x+1，同时也为自己选择一个初始序号seq = y。这时TCP服务器进程进入SYN-RCVD状态。
  - 第三次：TCP客户端收到服务器端的确认后，还要向服务器发送确认。确认报文段的ACK置为1，确认号为ack = y+1，而自己的序号seq = x + 1。这时TCP连接已建立，A进入ESTABLISHED（已建立连接）状态。
- 四次挥手
  - 第一次：客户进程向其TCP发送连接释放报文段，并停止再发数据，主动关闭TCP连接。客户进程把连接释放报文段的终止控制位FIN置为1，序号seq = u。这时客户进程进入FIN-WAIT-1（终止等待1）状态，等待B的确认。
  - 第二次：服务器进程收到连接释放报文后发出确认，确认号是ack=u+1，而这个报文段自己的需要是seq = v。然后服务端进程就进入了CLOSE-WAIT（关闭等待状态）。客户进程若收到来自服务器进程的确认后，就进入FIN-WAIT-2（终止等待2状态），等待服务器进程发出的连接释放报文段。注意此时TCP服务器进程应通知高层应用进程，因而从客户进程到服务器进程的连接就释放了，这时的TCP处于``**半连接状态**``（half-close），即客户端已经没有数据要发送了，但服务端要发送数据，客户端仍要接收。换句话说，``**从服务器进程到客户进程这个方向的连接并未关闭，这个状态可能会持续一段时间。**
  - 第三次：若服务器进程已经没有要向客户进程发送的数据，其应用进程就通知TCP释放连接。这时服务器端发出的连接释放报文段必须将FIN置为1。现在服务器进程报文段的需要为w（中间发送了一些数据），服务器进程必须重复上次已经发过的的确认号ack = u + 1。这时服务器进程就进入LAST-ACK（最后确认）状态。
  - 第四次：客户进程在收到服务进程的连接释放报文段后，必须对此发出确认。在确认报文段中把ACK置为1，确认号等于ack=w+1，而自己的序号是seq = u+1。然后进入到TIME-WAIT（时间等待）状态。注意**现在的TCP还没有释放掉**``，必须经过``**时间等待计时器**``设置的时间2MSL后，客户进程才会进入到CLOSED状态。
超大概率为什么三次握手最后客户进程要再发一次确认？（为什么两次握手不行？）
- 为了防止已失效的连接请求报文段突然又传送到了服务器进程，因而产生错误。
- 举例说明：客户进程发出的第一个连接请求报文段没有丢失，而是在某些网络结点长时间滞留，以致延误到连接释放以后的某个时间才到达服务器进程。这个本来是一个早已失效的报文段，但服务器进程收到这个失效的报文段后，就误认为客户进程又发出了一次新的连接请求。于是向客户进程发出确认报文段，同意建立连接。假如这种情况下不采用三次握手，那么只要服务器进程发出确认，新的连接就会建立。因为现在客户进程没有发出建立连接的请求，因此不会理睬服务器进程的确认，也不会向服务器进程发送数据。但是服务器进程却以为新的运输连接已经建立了，并一直等待客户进程发来数据，服务器进程的许多资源就浪费掉了。
大概率为什么四次挥手中客户进程在TIME-WAIT状态必须等待2MSL的时间 ？
- 为了保证客户进程发送的最后一个ACK报文段能够到达服务器进程。因为在服务器进程向客户进程发送最后一次ACK后，客户进程会返回一个ACK。如果客户进程返回的ACK在传输过程中丢失的话，过一段时间服务器进程会超时重传这个ACK。如果客户进程发送完ACK后，立即释放连接，那么就可能会接收不到服务器进程超时重传的ACK报文段。
- 防止已失效的连接请求报文段出现在本连接中。客户进程在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。
说一说TCP拥塞控制和流量控制？
- 超大概率谈一下TCP 拥塞控制？
  - 拥塞控制是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制是一个全局性的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。
  - TCP拥塞控制的四种方法
    - 慢开始：当主机开始发送数据时，由于并不清楚网络的负荷情况，所以如果立即把大量数据字节注入到网络，就有可能引起网络发生拥塞。较好的方法是先探测一下，由小到大逐渐增大发送窗口，即由小到大逐渐增大拥塞窗口的数值。每经过一个传输轮次，拥塞窗口就加倍。
    - 拥塞避免：让拥塞窗口缓慢增大，即每经过一个往返时间RTT就把发送方的拥塞窗口加1，而不是像慢开始阶段加倍的增长。因此在拥塞避免阶段有加法增大的特点。
    - 快重传：要求接收方不要等待自己发送数据时才捎带确认，而是要立即发送确认，即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。发送方只要一连收到3个重复确认，就知道接收法没有收到报文段，因而应当立即重传（快重传），这样就不会出现超时，发送方也就不会误认为出现了网络拥塞。
    - 快恢复：发送方在知道现在只是丢失了个别的报文段，于是不启动慢开始，而是执行快恢复算法。发送方调整门限值ssthresh=cwnd/2，同时设置拥塞窗口cwnd=ssthresh，并开始执行拥塞避免算法。
- 超大概率谈一下TCP 流量控制？
  - 流量控制是点对点通信量的控制，是个端到端的问题（接收端控制发送端）。流量控制要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。
大概率如何实现TCP可靠传输 ?
- 应用数据被分割为TCP认为最适合发送的数据块。
- TCP给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
- 校验和：TCP将保持它首部和数据的校验和。这是一个端到端的校验和，目的是检测数据在传输过程中的任何变化。如果收到的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段。
- TCP的接收端会丢弃重复的数据。
- 流量控制：TCP连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP使用的流量控制协议是可变大小的滑动窗口协议。（TCP利用滑动窗口实现流量控制）
- 拥塞控制：当网络拥塞时，减少数据的发送。
- ARQ协议：为了实现可靠传输，它的基本原理是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
  - 停止等待协议：每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。
  - 连续ARQ协议：发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。
- 超时重传：当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。
从输入网址到获得页面的过程 ?
- 首先查询一下DNS缓存，如果没有就进行DNS解析，得到IP地址。
- 浏览器获得IP地址后，向服务器请求建立连接，发起TCP三次握手。
- TCP/IP建立起来后，浏览器向服务器发送HTTP请求。
- 服务器接收到请求后，根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器。
- 浏览器获得到HTML对象进行页面渲染。
大概率DNS协议 ?
- 由于IP地址具有不方便记忆并且不能显示地址组织的名称和性质等缺点，人们设计出域名。并通过域名解析协议（DNS）来将域名和IP地址互相映射。
- 大概率DNS查询方式 ?
  - 递归查询：主机和本地域名服务器之间的查询方式是递归查询。
  - 迭代查询：如果请求的接收者不知道所请求的内容，那么接收者将扮演请求者，发出有关请求，直到获得所需要的内容，然后将内容返回给最初的请求者。一般来说，域名服务器之间的查询使用迭代查询方式，以免根域名服务器的压力过大。
- 大概率完整DNS域名解析过程？
  1. 首先搜索浏览器的DNS缓存，缓存中维护一张域名与IP地址的对应表。
  2. 若没有命中，则继续搜索操作系统的DNS缓存。
  3. 若仍然没有命中，则操作系统将域名发送至本地域名服务器，本地域名服务器查询自己的DNS缓存，查找成功则返回结果。主机和本地域名服务器之间的查询方式是递归查询。
  4. 若本地域名服务器的DNS缓存没有命中，则本地域名服务器向上级域名服务器进行查询，通过以下方式进行迭代查询。域名服务器之间的查询使用迭代查询方式，以免根域名服务器的压力过大。
    - 首先本地域名服务器向根域名服务器发起请求，根域名服务器是最高层次，它并不会直接指明这个域名对应的IP地址，而是返回顶级域名服务器的地址，也就是说给本地域名服务器指明一条道路，让他去这里寻找答案。
    - 本地域名服务器拿到这个顶级域名服务器的地址后，就向其发起请求，获取权限域名服务器的地址。
    - 本地域名服务器根据权限域名服务器的地址向其发起请求，最终获得该域名对应的IP地址。
  5. 本地域名服务器将得到的IP地址返回给操作系统，同时将自己的IP地址缓存起来。
  6. 操作系统将IP地址返回给浏览器，同时也将自己的IP地址缓存起来。
  7. 至此，浏览器就获得了自己的IP地址，并把IP地址缓存起来。
中概率说一下 http 和 https 协议的区别 ？
- https是超文本传输协议，信息是明文传输；https则是具有安全性的ssl加密传输协议。
- http和https使用的是完全不同的连接方式，用的端口也不一样，http使用的端口是80，https使用的端口是443。
- http的连接很简单，是无状态的；https协议是由SSL + HTTP 协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
TCP/IP协议的五层？五层模型的各自作用是什么？
OSI七层网络 ?
- 应用层
- 表示层
- 会话层
- 传输层
- 网络层
- 数据链路层
- 物理层
小概率accept()之后就建立连接吗？
- accept过程发生在三次握手之后，三次握手完成后，客户端和服务器端进程就建立了TCP连接，并可以进行数据交互了。这时调用accept函数获得此连接。
谈一下对SSL/TLS的了解？
- 互联网的通信安全，建立在SSL/TLS上。使用SSL/TLS协议能够保证所有信息都是加密过的，第三方无法窃听；SSL/TLS协议具有校验机制，一旦被篡改，通信双方就会立刻发现；配备身份证书，防止身份被冒充。
https采用的对称加密算法还是非对称加密算法？
- https采用SSL/TLS协议，SSL/TLS基本思路是采用公钥加密法。即客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。
项目问题谈一下心跳机制？
- 应用场景：在长连接下，有可能很长一段时间没有数据往来。从理论上来说，这个连接是可以一直保持连接的。但是在实际情况中，如果中间结点出现什么故障是很难预计的。此外，有的节点（防火墙）会自动把一定时间之内没有数据的连接断开。在这种场景下，就可以使用心跳机制用来维持长连接保活。
- 什么是心跳机制 ?
  - 每隔几分钟发送一个固定信息给服务器端，服务器端收到后会回复一个固定信息。如果服务器端几分钟没有收到客户端信息，则视客户端断开。
- 心跳机制实现的两种方式？
  - 应用层自己实现心跳机制：由应用程序自己发送心跳包来检测连接是否正常，服务器每隔一段时间向客户端发送一个较小的数据包，然后启动一个线程，在线程中不断检测客户端的回应。
  - 使用SO_KEEPALIVE套接字选项：在TCP机制中，本身是存在有心跳包的机制，也就是TCP的选项。无论是服务端还是客户端，一方开启KEEPALIVE功能后，就会自动在规定时间内向对方发送心跳包，而另一方收到心跳包后会自动回复。默认超时时间为2小时，时间太长所以需要指定KEEPALIVE参数。但是这种实现方式，检查不到机器断电、防火墙断线、网线拔出这些情况。
    - 开启SO_KEEPALIVE选项可能会出现三种情况：
      - 对方接收一切正常：以期望的ACK响应，在设置检测时间后，TCP将发出另一个探测分节。
      - 对方已崩溃且重新启动：以RST响应，套接口的待处理错误被置为ECONNECTSET，套接口本身则被关闭。
      - 对方无任何响应：套接口的待处理错误被置为ETIMEOUT，套接口本身则关闭。
quic协议（quick udp internet connections）协议
- 一种全新的基于udp的web开发协议。可以概括为TCP + TLS + HTTP2 = UDP + QUIC + HTTP2's api
- quic协议虽然是基于UDP，但它不仅具有TCP的可靠性、拥塞控制、流量控制等，且在TCP协议的基础上做了一些改进，比如避免队首阻塞。另外，quic协议具有TLS的安全传输特性，实现了TLS的保密功能，同时又使用更少的RTT建立安全的会话。
- quic协议的主要目的
  - 为了整合TCP协议的可靠性和UDP协议的速度和效率。
- https://blog.csdn.net/chenhaifeng2016/article/details/79011059

TCP粘包，拆包及解决方法