传输层(TCP/UDP)
TCP
1. 传输层：（段或数据报）
-
传输层负责将上层数据分段并提供端到端的、可靠的或不可靠的传输以及端到端的差错控制和流量控制；
-
包含的主要协议：TCP协议（Transmission Control Protocol，传输控制协议）、UDP协议（User Datagram Protocol，用户数据报协议）；
-
重要设备：。
2. 描述TCP头部？
-
至少20个字节（20字节的固定首部）
-
序号（32bit）：传输方向上字节流的字节编号。初始时序号会被设置一个随机的初始值（ISN），之后每次发送数据时，序号值 = ISN + 数据在整个字节流中的偏移。假设A -> B且ISN = 1024，第一段数据512字节已经到B，则第二段数据发送时序号为1024 + 512。用于解决网络包乱序问题。
-
确认号（32bit）：接收方对发送方TCP报文段的响应，其值是收到的序号值 + 1。
-
首部长（4bit）：标识首部有多少个4字节 * 首部长，最大为15，即60字节。
-
标志位（6bit）：
-
URG：标志紧急指针是否有效。
-
ACK：标志确认号是否有效（确认报文段）。用于解决丢包问题。
-
PSH：提示接收端立即从缓冲读走数据。
-
RST：表示要求对方重新建立连接（复位报文段）。
-
SYN：表示请求建立一个连接（连接报文段、请求同步标志）。
-
FIN：表示关闭连接（断开报文段）。
-
窗口（16bit）：接收窗口。用于告知对方（发送方）本方的缓冲还能接收多少字节数据。用于解决流控。
-
校验和（16bit）：接收端用CRC检验整个报文段有无损坏。
-
3. 三次握手过程？
-
第一次：客户端发含SYN位，SEQ_NUM = S的包到服务器。（客 -> SYN_SEND）
-
第二次：服务器发含ACK，SYN位且ACK_NUM = S + 1，SEQ_NUM = P的包到客户机。（服 -> SYN_RECV）
-
第三次：客户机发送含ACK位，ACK_NUM = P + 1的包到服务器。（客 -> ESTABLISH，服 -> ESTABLISH）
4. 四次挥手过程？
-
第一次：客户机发含FIN位，SEQ = Q的包到服务器。（客 -> FIN_WAIT_1）
-
第二次：服务器发送含ACK且ACK_NUM = Q + 1的包到服务器。（服 -> CLOSE_WAIT，客 -> FIN_WAIT_2）
- 此处有等待
-
第三次：服务器发送含FIN且SEQ_NUM = R的包到客户机。（服 -> LAST_ACK，客 -> TIME_WAIT）
- 此处有等待
-
第四次：客户机发送最后一个含有ACK位且ACK_NUM = R + 1的包到客户机。（服 -> CLOSED）
5. 为什么握手是三次，挥手是四次？
-
对于握手：握手只需要确认双方通信时的初始化序号，保证通信不会乱序。
（第三次握手必要性：假设服务端的确认丢失，连接并未断开，客户机超时重发连接请求，这样服务器会对同一个客户机保持多个连接，造成资源浪费。） -
对于挥手：TCP是双工的，所以发送方和接收方都需要FIN和ACK。只不过有一方是被动的，所以看上去就成了4次挥手。
6. TCP连接状态？
-
CLOSED：连接断开状态。
-
LISTEN：服务器处于监听状态。
-
SYN_SEND：客户端socket执行CONNECT连接，发送SYN包，进入此状态。
-
SYN_RECV：服务端收到SYN包并发送服务端SYN包，进入此状态。
-
ESTABLISH：表示连接建立。客户端发送了最后一个ACK包后进入此状态，服务端接收到ACK包后进入此状态。
-
FIN_WAIT_1：终止连接的一方（通常是客户机）发送了FIN报文后进入。等待对方FIN。
-
CLOSE_WAIT：（假设服务器）接收到客户机FIN包之后等待关闭的阶段。在接收到对方的FIN包之后，自然是需要立即回复ACK包的，表示已经知道断开请求。
但是本方是否立即断开连接（发送FIN包）取决于是否还有数据需要发送给客户端，若有，则在发送FIN包之前均为此状态。 -
FIN_WAIT_2：此时是半连接状态，即有一方要求关闭连接，等待另一方关闭。客户端接收到服务器的ACK包，但并没有立即接收到服务端的FIN包，进入FIN_WAIT_2状态。
-
LAST_ACK：服务端发动最后的FIN包，等待最后的客户端ACK响应，进入此状态。
-
TIME_WAIT：客户端收到服务端的FIN包，并立即发出ACK包做最后的确认，在此之后的2MSL时间称为TIME_WAIT状态。
7. 解释FIN_WAIT_2，CLOSE_WAIT状态和TIME_WAIT状态？
-
FIN_WAIT_2：
-
半关闭状态。
-
发送断开请求一方还有接收数据能力，但已经没有发送数据能力。
-
-
CLOSE_WAIT状态：
-
被动关闭连接一方接收到FIN包会立即回应ACK包表示已接收到断开请求。
-
被动关闭连接一方如果还有剩余数据要发送就会进入CLOSED_WAIT状态。
-
-
TIME_WAIT状态：
-
又叫2MSL等待状态。
-
如果客户端直接进入CLOSED状态，如果服务端没有接收到最后一次ACK包会在超时之后重新再发FIN包，此时因为客户端已经CLOSED，所以服务端就不会收到ACK而是收到RST。
所以TIME_WAIT状态目的是防止最后一次握手数据没有到达对方而触发重传FIN准备的。 -
在2MSL时间内，同一个socket不能再被使用，否则有可能会和旧连接数据混淆（如果新连接和旧连接的socket相同的话）。
-
8. 解释RTO，RTT和超时重传？
-
超时重传：发送端发送报文后若长时间未收到确认的报文则需要重发该报文。可能有以下几种情况：
-
发送的数据没能到达接收端，所以对方没有响应。
-
接收端接收到数据，但是ACK报文在返回过程中丢失。
-
接收端拒绝或丢弃数据。
-
-
RTO：从上一次发送数据，因为长期没有收到ACK响应，到下一次重发之间的时间。就是重传间隔。
-
通常每次重传RTO是前一次重传间隔的两倍，计量单位通常是RTT。例：1RTT，2RTT，4RTT，8RTT…
-
重传次数到达上限之后停止重传。
-
-
RTT：数据从发送到接收到对方响应之间的时间间隔，即数据报在网络中一个往返用时。大小不稳定。
9. 流量控制原理？
-
目的是接收方通过TCP头窗口字段告知发送方本方可接收的最大数据量，用以解决发送速率过快导致接收方不能接收的问题。所以流量控制是点对点控制。
-
TCP是双工协议，双方可以同时通信，所以发送方接收方各自维护一个发送窗和接收窗。
-
发送窗：用来限制发送方可以发送的数据大小，其中发送窗口的大小由接收端返回的TCP报文段中窗口字段来控制，接收方通过此字段告知发送方自己的缓冲（受系统、硬件等限制）大小。
-
接收窗：用来标记可以接收的数据大小。
-
-
TCP是流数据，发送出去的数据流可以被分为以下四部分：已发送且被确认部分 | 已发送未被确认部分 | 未发送但可发送部分 | 不可发送部分，其中发送窗 = 已发送未确认部分 + 未发但可发送部分。
接收到的数据流可分为：已接收 | 未接收但准备接收 | 未接收不准备接收。接收窗 = 未接收但准备接收部分。 -
发送窗内数据只有当接收到接收端某段发送数据的ACK响应时才移动发送窗，左边缘紧贴刚被确认的数据。接收窗也只有接收到数据且最左侧连续时才移动接收窗口。
10. 拥塞控制原理？
-
拥塞控制目的是防止数据被过多注网络中导致网络资源（路由器、交换机等）过载。因为拥塞控制涉及网络链路全局，所以属于全局控制。控制拥塞使用拥塞窗口。
-
TCP拥塞控制算法：
-
慢开始 & 拥塞避免：先试探网络拥塞程度再逐渐增大拥塞窗口。每次收到确认后拥塞窗口翻倍，直到达到阀值ssthresh，这部分是慢开始过程。达到阀值后每次以一个MSS为单位增长拥塞窗口大小，当发生拥塞（超时未收到确认），将阀值减为原先一半，继续执行线性增加，这个过程为拥塞避免。
-
为了防止cwnd增长过大引起网络拥塞，还需设置一个慢开始门限ssthresh状态变量。ssthresh的用法如下：
当cwnd<ssthresh时，使用慢开始算法。 当cwnd>ssthresh时，改用拥塞避免算法。 当cwnd=ssthresh时，慢开始与拥塞避免算法任意。 -
拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口按线性规律缓慢增长。
-
无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认，虽然没有收到确认可能是其他原因的分组丢失，但是因为无法判定，所以都当做拥塞来处理），就把慢开始门限设置为出现拥塞时的发送窗口大小的一半。然后把拥塞窗口设置为1，执行慢开始算法。
-
-
快速重传 & 快速恢复：
- 快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
-
最终拥塞窗口会收敛于稳定值。
-
11. 如何区分流量控制和拥塞控制？
-
流量控制属于通信双方协商；拥塞控制涉及通信链路全局。
-
流量控制需要通信双方各维护一个发送窗、一个接收窗，对任意一方，接收窗大小由自身决定，发送窗大小由接收方响应的TCP报文段中窗口值确定；
拥塞控制的拥塞窗口大小变化由试探性发送一定数据量数据探查网络状况后而自适应调整。 -
实际最终发送窗口 = min{流控发送窗口，拥塞窗口}。
12. TCP如何提供可靠数据传输的？
-
建立连接（标志位）：通信前确认通信实体存在。
-
序号机制（序号、确认号）：确保了数据是按序、完整到达。
-
数据校验（校验和）：CRC校验全部数据。
-
超时重传（定时器）：保证因链路故障未能到达数据能够被多次重发。
-
窗口机制（窗口）：提供流量控制，避免过量发送。
-
拥塞控制：同上。
13. 为什么要三次挥手？
- 在只有两次"握手"的情形下，假设Client想跟Server建立连接，但是却因为中途连接请求的数据报丢失了，故Client端不得不重新发送一遍；这个时候Server端仅收到一个连接请求，因此可以正常的建立连接。但是，有时候Client端重新发送请求不是因为数据报丢失了，而是有可能数据传输过程因为网络并发量很大在某结点被阻塞了，这种情形下Server端将先后收到2次请求，并持续等待两个Client请求向他发送数据…问题就在这里，Cient端实际上只有一次请求，而Server端却有2个响应，极端的情况可能由于Client端多次重新发送请求数据而导致Server端最后建立了N多个响应在等待，因而造成极大的资源浪费！所以，"三次握手"很有必要！
14. 为什么要四次挥手？
- 试想一下，假如现在你是客户端你想断开跟Server的所有连接该怎么做？第一步，你自己先停止向Server端发送数据，并等待Server的回复。但事情还没有完，虽然你自身不往Server发送数据了，但是因为你们之前已经建立好平等的连接了，所以此时他也有主动权向你发送数据；故Server端还得终止主动向你发送数据，并等待你的确认。其实，说白了就是保证双方的一个合约的完整执行！
15. 使用TCP的协议：FTP（文件传输协议）、Telnet（远程登录协议）、SMTP（简单邮件传输协议）、POP3（和SMTP相对，用于接收邮件）、HTTP协议等。
UDP
16. UDP用户数据报协议，是面向无连接的通讯协议，UDP数据包括目的端口号和源端口号信息，由于通讯不需要连接，所以可以实现广播发送。
17. UDP的应用？
- UDP通讯时不需要接收方确认，属于不可靠的传输，可能会出现丢包现象，实际应用中要求程序员编程验证。UDP与TCP位于同一层，但它不管数据包的顺序、错误或重发。
因此，UDP不被应用于那些使用虚电路的面向连接的服务，UDP主要用于那些面向查询—应答的服务，例如NFS。相对于FTP或Telnet，这些服务需要交换的信息量较小。
18. UDP头部？
-
每个UDP报文分UDP报头和UDP数据区两部分。报头由四个16位长（2字节）字段组成，分别说明该报文的源端口、目的端口、报文长度以及校验值。UDP报头由4个域组成，其中每个域各占用2个字节，具体如下：
（1）源端口号；
（2）目标端口号；
（3）数据报长度；
（4）校验值。