如果同个浏览器发起第二次要求给做事器时，它还是会相应。但是呢，做事器不知道你便是刚才的那个浏览器。
简而言之，做事器不会去记住你是谁，所以是无状态协议。
4.简述从浏览器地址栏输入url到显示主页的过程DNS解析，查找域名对应的IP地址。与做事器通过三次握手，建立TCP连接。向做事器发送HTTP要求。做事器处理要求，返回网页内容。浏览器解析并渲染页面。TCP四次握手，连接结束。
HTTP/1.0
默认利用短连接，每次要求都须要建立一个TCP连接。它可以设置Connection: keep-alive 这个字段，逼迫开启长连接。
HTTP/1.1
默认利用长连接，即TCP连接默认不关闭，可以被多个要求复用。分块传输编码，即做事端每产生一块数据，就发送一块，用“流模式”取代“缓存模式”。管道机制，即在同一个TCP连接里面，客户端可以同时发送多个要求。HTTP/2.0
二进制协议，1.1版本的头信息是文本（ASCII编码），数据体可以是文本或二进制；2.0中，头信息和数据体都是二进制。完备多路复用，在一个连接里，客户端和做事器都可以同时发送多个要求或相应，而且不用按照顺序逐一对应。报头压缩，HTTP协议不带有状态，每次要求都必须带上所有信息。HTTP/2.0引入了头信息压缩机制，利用gzip或compress压缩后再发送。做事端推送，许可做事器未经要求，主动向客户端发送资源。6.POST和GET有哪些差异7.HTTP 如何实现长连接？在什么时候会超时？什么是HTTP的长连接？
HTTP分为长连接和短连接，实质上说的是TCP的是非连接。TCP连接是一个双向的通道，它是可以保持一段韶光不关闭的，因此TCP连接才具有真正的长连接和短连接这一说法。TCP长连接可以复用一个TCP连接，来发起多次HTTP要求，这样就可以减少资源花费，比如一次HTML要求，如果是短连接的话，可能还须要要求后续的JS/CSS。如何设置长连接？
通过在要求头和相应头设置Connection字段指定为keep-alive，HTTP/1.0协议支持，但默认是关闭的，从HTTP/1.1往后，连接默认都是长连接。
在什么时候会超时？
HTTP一样平常会有httpd守护进程，里面可以设置keep-alive timeout，当tcp连接闲置超过这个韶光就会关闭，也可以在HTTP的header里面设置超时时间。TCP 的keep-alive包含三个参数，支持在系统内核的net.ipv4里面设置；当 TCP 连接之后，闲置了tcp_keepalive_time，则会发生侦测包，如果没有收到对方的ACK，那么会每隔 tcp_keepalive_intvl 再发一次，直到发送了tcp_keepalive_probes，就会丢弃该连接。tcp_keepalive_intvl = 15tcp_keepalive_probes = 5tcp_keepalive_time = 18001238.HTTP 与 HTTPS 的差异
HTTP 即超文本传输协议，是一个基于TCP/IP通信协议来通报明文数据的协议。HTTP会存在这几个问题：
要求信息是明文传输，随意马虎被窃听截取。没有验证对方身份，存在被伪装的风险。数据的完全性未校验，随意马虎被中间人修改。为理解决HTTP存在的问题，HTTPS涌现啦。
HTTPS是什么？
HTTPS= HTTP+SSL/TLS，可以理解为 HTTPS 是身披 SSL（Secure Socket Layer，安全套接层）的HTTP。
它们的紧张差异如下：
9.HTTPS的事情流程是若何的？HTTPS = HTTP + SSL/TLS，也便是用SSL/TLS对数据进行加密和解密，用HTTP进行传输。SSL，即Secure Sockets Layer（安全套接层协议），是网络通信供应安全及数据完全性的一种安全协议。TLS，即Transport Layer Security（安全传输层协议），它是SSL3.0的后续版本。
客户端发起HTTPS要求，连接到做事器的443端口。做事器必须要有一套数字证书（证书内容有公钥、证书颁发机构、失落效日期等）。做事器将自己的数字证书发送给客户端（公钥在证书里面，私钥由做事器持有）。客户端收到数字证书之后，会验证证书的合法性。如果证书验证通过，就会天生一个随机的对称密钥，用证书的公钥加密。客户端将公钥加密后的密钥发送到做事器。做事器吸收到客户端发来的密文密钥之后，用自己之前保留的私钥对其进行非对称解密，解密之后就得到客户真个密钥，然后用客户端密钥对返回数据进行对称加密，这样子传输的数据都是密文啦。做事器将加密后的密文返回到客户端。客户端收到后，用自己的密钥对其进行对称解密，就能得到做事器返回的数据。10.说说HTTP的状态码，301和302的差异？301：永久重定向，表示所要求的资源已经永久地转移到新的位置，这包含域名的改变或者是资源路径的改变。302：临时重定向，表示所要求的资源临时地转移到新的位置，一样平常是24到48小时以内的转移会用到302。11.说说什么是数字署名？什么是数字证书？数字证书构成：
公钥和个人等信息，经由Hash算法加密，形成择要；将择要拿到拥有公信力的认证中央（CA），用它的私钥对择要加密，形成数字署名。公钥和个人信息、数字署名共同构成数字证书。12.对称加密和非对称加密有什么差异对称加密：指加密和解密利用同一密钥，优点是运算速率较快，缺陷是不能安全地将密钥传输给另一方。常见的对称加密算法有：DES、AES等。
非对称加密：指的是加密和解密利用不同的密钥（即公钥和私钥）。公钥与私钥是成对存在的，如果用公钥对数据进行加密，只有对应的私钥才能解密。常见的非对称加密算法有 RSA。
13.说说 DNS 的解析过程？
DNS的解析过程如下图：
假设你要查询www.baidu.com的IP地址：浏览器 -> 本地DNS做事器 -> 根域名做事器 -> 顶级域名做事器 -> 威信域名做事器
首先会查找浏览器的缓存，看看是否能找到www.baidu.com对应的IP地址，找到就直接返回；否则进行下一步。将要求发往本地DNS做事器，如果查找到也直接返回，否则连续进行下一步；本地DNS做事器向根域名做事器发送要求，根域名做事器返回卖力.com的顶级域名做事器的列表。本地DNS做事器再向个中一个顶级域名做事器发送一个要求，返回卖力.baidu的威信域名做事器的列表。本地DNS做事器再向个中一个威信域名做事器发送一个要求，返回www.baidu.com所对应的IP地址。14.说说 WebSocket与socket的差异Socket是一套标准，它完成了对TCP/IP的高度封装，屏蔽网络细节，以便开拓者更好地进行网络编程。
Socket即是IP地址 + 端口 + 协议。
WebSocket是一个持久化的协议，它是伴随H5而出的协议，用来办理HTTP不支持持久化连接的问题。
Socket是一个网络编程的标准接口，而WebSocket则是运用层通信协议。
15.HTTP要求的过程与事理HTTP是一个基于TCP/IP协议来通报数据的超文本传输协议，传输的数据类型有HTML、图片等。
客户端进行DNS域名解析，得到对应的IP地址根据这个IP地址，找到对应的做事器建立TCP连接（三次握手）建立TCP连接后发起HTTP要求（一个完全的http要求报文）做事器相应HTTP要求，客户端得到html代码客户端解析html代码，用html代码中的资源（如 js、css、图片等等）渲染页面。做事器关闭TCP连接（四次挥手）16.forward和redirect的差异？
是servlet中的两种紧张跳转办法。forward：转发，redirect：重定向
从地址栏显示来说forward是做事器内部的重定向，做事器直接访问目标地址，把里面的东西取出来，但是客户端并不知道，因此用forward的话，客户端浏览器的网址是不会发生变革的。
redirect是做事器根据逻辑，发送一个状态码，见告浏览看重新去要求那个地址，以是地址栏显示的是新地址。
从数据共享来说由于在全体转发的过程中利用的是同一个request，因此forward会将request信息带到被重定向的jsp或servlet中利用，即可以共享数据。
redirect不能共享数据。
从利用的地方来说forward一样平常用于用户登录时，根据角色转发到相应的模块
redirect一样平常用于用户注销登录时返回主页面
从实质上来说forward转发是做事器上的行为，redirect重定向是客户真个行为。
从效率上来说forword效率高，而redirect效率低。
从要求的次数来说forword只有一次要求，而redirect有两次要求。
17.Session和Cookie的差异Cookie 是保存在客户真个一小块文本串的数据。客户端向做事器发起要求时，做事器会向客户端发送一个 Cookie，客户端就把 Cookie 保存起来。下次向同一做事器再发起要求时，Cookie 就被携带发送到做事器。做事器可以根据这个 Cookie 判断用户的身份和状态。
Session 指的是做事器和客户端一次会话的过程。它是另一种记录客户端状态的机制。不同的是 Cookie 是保存在客户端浏览器中的，而 Session 是保存在做事器上的。客户端浏览器在访问做事器时，做事器会把客户端信息以某种形式记录在做事器上，这便是 Session。客户端浏览器再次访问时只须要从该 Session 中查找用户的状态。
Session 和 Cookie 到底有什么不同呢？
Session 和 Cookie 有什么关联呢？
可以利用 Cookie 记录 Session 的唯一标识
用户第一次要求做事器时，做事器根据用户提交的信息，创建对应的Session，要求返回时将此Session的唯一标识信息SessionID返回给浏览器，浏览器会将此SessionID信息存入Cookie中，同时Cookie记录此SessionID是属于哪个域名的。当用户第二次访问做事器时，要求会自动判断此域名下是否存在Cookie信息，如果存在，则自动将Cookie信息也发送给做事器，做事器会从Cookie中获取SessionID，再根据 SessionID 查找对应的 Session 信息，如果没有找到则解释用户没有登录或者登录失落效，如果找到则证明用户已经登录可实行后面的操作。
分布式环境下 Session 该怎么处理呢？
分布式环境下，客户端要求经由负载均衡，可能会分配到不同的做事器上，如果一个用户的要求两次没有落到同一台做事器上，那么在新的做事器上就没有记录该用户状态对应的 Session。
可以利用 Redis 等分布式缓存来存储 Session，担保在多台做事器间共享。
客户端如果无法利用 Cookie 怎么办呢？
有可能客户端无法利用 Cookie，比如浏览器禁用 Cookie，或者客户端是 安卓、IOS 设备等。
这时候怎么办呢？SessionID 怎么存呢？怎么传给做事器呢？
首先是 SessionID 的存储，可以利用客户真个本地存储，比如浏览器的 sessionStorage。
接下来要怎么传呢？
拼接到 URL：直接把 SessionID 作为 URL 的要求参数。放到要求头：把 SessionID 放到要求头里面，比较常用。18.详细说一下 TCP 的三次握手机制TCP 三次握手过程：
最开始，客户端和做事端都处于 CLOSE（关闭）状态，做事端监听客户真个要求，进入 LISTEN（监听） 状态。客户端发送连接要求，进行第一次握手（同步位 SYN=1，序号字段 seq=x），发送完毕后，客户端就进入 SYN_SENT（同步已发送） 状态。做事端确认连接，进行第二次握手（同步位 SYN=1，确认位 ACK=1，序号字段 seq=y，确认号字段 ack=x+1）， 发送完毕后，做事端就进入 SYN_RCV（同步已吸收） 状态。客户端收到做事端的确认后，再次向做事端确认，进行第三次握手（确认位 ACK=1，确认号字段 ack=y+1），发送完毕后，客户端就进入 ESTABLISHED（连接已建立） 状态，当做事端吸收到这个包时，也进入 ESTABLISHED（连接已建立） 状态。19.TCP 握手为什么是三次，为什么不能是两次？不能是四次？为什么不能是两次？
防止已失落效的连接要求报文段溘然又传到做事端，因而产生缺点
客户端发送出去的第一个连接要求报文段并没有丢失，而是由于某些未知缘故原由在某个网络节点上发生滞留，导致延迟到连接开释往后的某个韶光点才到达做事端。本来这是一个早已失落效的报文段，但是做事端收到此失落效的报文段后，会误认为这是客户端再次发起的一个新的连接要求，于是做事端向客户端又发出确认报文，表示赞许建立连接。如果不采取 “三次握手”，那么只要做事端发出确认报文后就会认为新的连接已经建立了，但是客户端并没有发出建立连接的要求，因此不会向做事端发送数据，做事端没有收到数据就会一贯等待，这样做事端就会白白摧残浪费蹂躏掉很多资源。
以是我们须要 “第三次握手” 来确认这个过程：
通过第三次握手的数据来见告做事端，客户端有没有收到做事端 “第二次握手” 时传过去的数据，以及这个连接的序号是不是有效的。若发送的这个数据是 “收到且没有问题” 的信息，做事端吸收后就可以正常建立 TCP 连接，否则建立 TCP 连接失落败，做事器关闭连接端口。由此减少做事器开销和吸收到失落效要求时发生的缺点。为什么不是四次？
大略来说，便是三次握手已经足够创建可靠的连接，没有必要再多一次握手导致花费更多的韶光在建立连接上。
20.三次握手中每一次没收到报文会发生什么情形？第一次握手做事端未收到 SYN 报文
做事端不会进行任何的动作，而客户端由于一段韶光内没有收到做事端发来的确认报文，等待一段韶光后会重新发送 SYN 报文，
如果仍旧没有回应，会重复这个过程，直到发送次数超过最大重传次数，就会返回连接建立失落败。
第二次握手客户端未收到做事端相应的 ACK 报文
由于第二次握手是包含对客户端第一次握手的 ACK 确认报文，以是如果客户端迟迟没有收到第二次握手，那么客户端就会以为可能是自己的 SYN 报文（第一次握手）丢失了，于是客户端就会触发超时重传机制，重传 SYN 报文。
然后，由于第二次握手是包含做事真个 SYN 报文，以是当客户端收到后，须要给做事端发送 ACK 确认报文（第三次握手），做事端才会认为该 SYN 报文被客户端收到了。
那么，如果第二次握手丢失了，做事端就收不到第三次握手，于是做事端这边会触发超时重传机制，重传 SYN-ACK 报文。
第三次握手做事端未收到客户端发送过来的 ACK 报文
客户端收到做事真个 SYN-ACK 报文后，就会给做事端发送一个 ACK 报文，也便是第三次握手，此时客户端进入到 ESTABLISH（连接已建立） 状态。
由于这个第三次握手的 ACK 是对第二次握手的 SYN 的确认报文，以是当第三次握手丢失了，如果做事端那一方迟迟收不到这个确认报文，就会触发超时重传机制，重传 SYN-ACK 报文，直到收到第三次握手，或者达到最大重传次数。
21.第二次握手传回了 ACK，为什么还要传回 SYN？ACK 是为了见告客户端传来的数据已经吸收无误。
而传回 SYN 是为了见告客户端，做事端相应的确实是客户端发送的报文。
22.第三次握手可以携带数据吗？第三次握手是可以携带数据的。
此时客户端已经处于连接已建立状态。对付客户端来说，它已经建立连接成功了，并且确认做事真个吸收和发送能力是正常的。
第一次握手不能携带数据是出于安全的考虑，由于如果许可携带数据，攻击者每次在 SYN 报文中携带大量数据，就会导致做事端花费更多的韶光和空间去处理这些报文，会造成CPU和内存的花费。
23.说说 TCP 四次挥手的过程？数据传输结束后，通信双方都可以主动发起断开连接要求，这里假定客户端发起。客户端发送开释连接报文，进行第一次挥手（FIN=1，ACK=1，seq=u，ack=v），发送完毕后，客户端进入 FIN_WAIT_1（终止等待1） 状态。做事端发送确认报文，进行第二次挥手（ACK=1，seq =v，ack=u+1），发送完毕后，做事端进入 CLOSE_WAIT（关闭等待） 状态，客户端收到这个确认包后，进入 FIN_WAIT_2（终止等待2） 状态。做事端发送开释连接报文，进行第三次挥手（FIN=1，ACK1，seq=w，ack=u+1），发送完毕后，做事端进入LAST_ACK（末了确认） 状态，等待来自客户真个末了一个 ACK 报文。客户端发送确认报文，进行第四次挥手（ACK=1，seq=u+1，ack=w+1），客户端收到来自做事真个关闭要求，发送一个确认包，并进入 TIME_WAIT（韶光等待） 状态，做事端吸收到这个确认包后，关闭连接，进入 CLOSED（关闭） 状态。客户端再经由 2MSL 后，也进入 CLOSED（关闭） 状态。客户端在发送完末了一个确认报文后，为什么不直接进入关闭状态 ? 而是要进入韶光等待状态，2MSL 后才进入关闭状态，这是否有必要呢 ?
做事端发送TCP连接开释报文段后进入末了确认状态。
客户端收到该报文段后，发送普通的TCP确认报文段，并进入关闭状态而不是韶光等待状态。然而，该TCP确认报文段丢失了。
这一定会造成做事端对之前所发送的TCP连接开释报文段的超时重传，并仍处于末了确认状态。重传的TCP连接开释报文段到达客户端，由于客户端处于关闭状态，因此不理睬该报文段，这一定会造成做事端反复重传TCP连接开释报文段，并一贯处于末了确认状态而无法进入关闭状态。
因此韶光等待状态以及处于该状态2MSL时长，可以确保做事端可以收到末了一个TCP确认报文段而进入关闭状态。
其余，客户端在发送完末了一个TCP确认报文段后，再经由2MSL时长，就可以使本次连接持续韶光内所产生的所有报文段都从网络中消逝，这样就可以使下一个新的TCP连接中，不会涌现旧连接中的报文段。
为什么等待韶光是2MSL？
MSL 是报⽂最⼤⽣存韶光，它是任何报⽂在⽹络上存在的最⻓韶光，超过这个韶光报⽂将被丢弃。
TIME_WAIT 等待 2 倍的 MSL，是由于⽹络中可能存在来⾃发送⽅的数据包，当这些发送⽅的数据包被吸收⽅处理后⼜会向对⽅发送相应，以是⼀来⼀回须要等待 2 倍的韶光。
⽐如做事端如果没有收到客户端发送的TCP确认报文段，就会触发超时重传，重新发送TCP连接开释报文段，客户端收到后，会重发TCP确认报文段给做事端， ⼀来⼀去恰好 2 个 MSL。
24.TCP 挥手为什么须要四次呢？再来回顾下四次挥手双方发 FIN 包的过程，就能理解为什么须要四次了。
关闭连接时，客户端向做事端发送 FIN 报文，仅仅表示客户端不再发送数据了但是还能吸收数据。
做事端收到客户真个 FIN 报文后，先返回一个 ACK 确认报文；而做事端可能还有数据须要处理和发送，等做事端不再发送数据了，再发送 FIN 报文给客户端来表示赞许现在关闭连接。
从上面的过程可知，做事端常日须要等待完成数据的发送和处理，以是做事真个 ACK 和 FIN 一样平常都会分开发送，从而导致比三次握手多了一次。
25.TCP 保活计时器有什么用？除了韶光等待计时器外，TCP 还有一个保活计时器（keepalive timer）。
设想这样的场景：
TCP 双方已经建立了连接，后来，客户真个主机溘然涌现了故障。显然，做事端往后就不能再收到客户端发来的数据。因此，应该有方法使做事端不要再白白等待下去。这就须要利用保活计时器了。
做事端每收到一次客户真个数据，就重新设置并启动保活计时器（2小时定时）。若定时周期内都没有收到客户端发来的数据，做事端就发送一个探测报文段，往后每隔 75 秒钟发送一次。若连续发送 10 个探测报文段后仍旧无客户真个相应，做事端就认为客户端出了故障，接着就关闭这个连接。
26.CLOSE-WAIT 的状态和意义？做事端收到客户端关闭连接的要求并确认之后，就会进入 CLOSE-WAIT 状态。
此时做事端可能还有一些数据没有传输完成，因此不能立即关闭连接，而 CLOSE-WAIT 状态便是为了担保做事端在关闭连接之前将待发送的数据处理完。
27.说说 TCP 报文首部有哪些字段？16位端口号：源端口号，标识发送该 TCP 报文段的运用进程；目的端口号，标识吸收该 TCP 报文段的运用进程。32位序号：指出本 TCP 报文段数据载荷的第一个字节的序号。32位确认号：指出期望收到对方下一个 TCP 报文段的数据载荷的第一个字节的序号，同时也是对之前收到的所有数据的确认。若确认号 = n，则表明到序号 n-1 为止的所有数据都已精确吸收，期望收到序号为 n 的数据。4位头部长度：指出 TCP 报文段的首部长度。6位标志位：确认标志位ACK：取值为1时确认号字段才有效，取值为0时确认号字段无效。TCP 规定，在连接建立后所有传送的 TCP 报文段都必须把 ACK 置为1。同步标志位SYN：在 TCP 连接建立时用来同步序号。终止标志位FIN：用来开释 TCP 连接。16位窗口大小：指出发送本报文段的一方的吸收窗口。窗口值作为吸收方让发送方设置其发送窗口的依据。这因此吸收方的吸收能力来掌握发送方的发送能力，称为流量掌握。发送窗口的大小还取决于拥塞窗口的大小，也便是该当从吸收窗口和拥塞窗口中取小者。16位校验和：用来检讨全体 TCP 报文段在传输过程中是否涌现了误码。16位紧急指针：当发送方有紧急数据时，可将紧急数据插队到发送缓存的最前面，并急速封装到一个 TCP 报文段中进行发送。紧急指针会指出本报文段的数据载荷部分包含了多长的紧急数据，紧急数据之后是普通数据。28.TCP 是如何担保可靠性的？TCP紧张供应了 连接管理、校验和、序列号/确认应答、流量掌握、最大长度、超时重传、拥塞掌握等办法实现了可靠传输。
连接管理：TCP 利用三次握手和四次挥手来担保可靠地建立连接和开释连接。校验和：用来检讨全体 TCP 报文段在传输过程中是否涌现了误码。序列号/确认应答：TCP 会给发送的每一个包进行编号，吸收方会对收到的包进行应答，发送方就会知道吸收方是否收到对应的包，如果创造没有收到，就会重发，这样就能担保数据的完全性了。流量掌握：TCP 连接的每一方都有固定大小的缓冲空间，TCP 的吸收端只许可发送端发送吸收端缓冲区能收受接管的数据大小。当吸收方来不及处理发送方的数据时，能提示发送方降落发送的速率，防止包丢失。TCP 利用的流量掌握协议是可变大小的滑动窗口协议。（TCP 利用滑动窗口实现流量掌握）最大长度：在建立 TCP 连接的时候，双方约定一个最大的长度（MSS）作为发送的单位，重传的时候也因此这个单位来进行重传的。空想情形下是该长度的数据刚好不被网络层分块。超时重传：超时重传是指发送出去的数据包到吸收到确认包之间的韶光，如果超过了这个韶光，就会被认为是丢包了，须要重传。拥塞掌握：如果网络非常拥堵，此时再发送数据就会加重网络包袱，那么发送的数据段很可能超过了最大生存韶光也没有到达吸收方，就会产生丢包问题。为此 TCP 引入了慢启动机制，先发出少量数据，就像探路一样，先摸清当前的网络拥堵状态后，再决定按照多大的速率传送数据。29.说说 TCP 的流量掌握？TCP 供应了一种机制，可以让发送方根据吸收方的实际吸收能力掌握发送的数据量，这便是流量掌握。
TCP 通过「滑动窗口」来实现流量掌握
首先 TCP 双方进行三次握手，初始化各自的窗口大小，均为 400 字节。如果当前发送方给吸收方发送了 200 字节，那么，发送方的SND.NXT会右移 200 字节，也便是说当前的可用窗口减少了 200 字节。吸收方收到后，放到缓冲行列步队里面，REV.WND = 400-200=200 字节，以是 win=200 字节返回给发送方。吸收方会在 ACK 的报文首部带上缩小后的滑动窗口 200 字节发送方又发送 200 字节过来，200 字节到达，连续放到缓冲行列步队里面。不过这时候，由于大量负载的缘故原由，吸收方处理不了这么多字节，只能处理 100 字节，剩余的 100 字节连续放到缓冲行列步队里面。这时候，REV.WND = 400-200-100=100 字节，即 win=100 字节返回给发送方。发送方连续发送 100 字节过来，这时候，吸收窗口 win 变为 0。发送方停滞发送，开启一个定时任务，每隔一段韶光，就去讯问吸收方，直到 win 大于 0，才开始连续发送。30.详细说说 TCP 的滑动窗口？TCP 发送一个数据，如果须要收到确认应答才会发送下一个数据。这样的话就会有个缺陷：效率会比较低。
为理解决这个问题，TCP 引入了滑动窗口，它是操作系统开辟的一个缓存空间。窗口大小表示无需等待确认应答而可以连续发送数据的最大值。
TCP 头部有个 16 位的窗口大小，它见告对方本真个 TCP 吸收缓冲区还能容纳多少字节的数据，这样对方就可以掌握发送数据的速率，从而达到流量掌握的目的。
普通点讲，便是吸收方每次收到数据包，在发送确认报文的时候，同时见告发送方，自己的吸收缓冲区还有多少空闲空间，缓冲区的空闲空间，我们就称之为吸收窗口大小。
TCP 滑动窗口分为两种: 发送窗口和吸收窗口。
发送方的滑动窗口包含四个部分：
已发送且已收到 ACK 确认已发送但未收到 ACK 确认未发送但可以发送未发送且不可发送虚线矩形框，便是发送窗口。SND.WND：表示发送窗口的大小，上图虚线框的格子数是 14 个，即发送窗口大小是 14。SND.NXT：下一个发送的位置，它指向未发送但可以发送的第一个字节的序列号。SND.UNA：一个绝对指针，它指向的是已发送但未收到确认的第一个字节的序列号。吸收方的滑动窗口包含三个部分：
已成功吸收并确认未收到数据但可以吸收未收到数据且不可以吸收的数据虚线矩形框，便是吸收窗口。REV.WND：表示吸收窗口的大小，上图虚线框的格子数便是 9 个，即吸收窗口的大小是 9。REV.NXT：下一个吸收的位置，它指向未收到但可以吸收的第一个字节的序列号。31.说说 TCP 的拥塞掌握？什么是拥塞掌握？不是有了流量掌握吗？
前⾯的流量掌握是避免发送⽅的数据填满吸收⽅的缓存，但是并不知道全体⽹络中发⽣了什么。
⼀般来说，打算机⽹络都处在⼀个共享的环境。因此也有可能会由于其他主机之间的通信使得⽹络涌现拥堵。
在⽹络涌现拥堵时，如果连续发送⼤量数据包，可能会导致数据包延迟、丢失等，这时 TCP 就会重传数据，但是⼀重传就会导致⽹络的包袱更重，于是会导致更⼤的延迟以及更多的丢包，这个情形就会进⼊恶性循环并且被不断地放⼤…
以是，TCP 不能忽略全体网络中发⽣的事，它被设计成⼀个⽆私的协议，当⽹络发送拥塞时，TCP 会⾃我捐躯，降落发送的数据流。
于是，就有了拥塞掌握，拥塞掌握的⽬的便是为了避免发送⽅的数据填满全体⽹络。
就像是一个水管，不能让太多的水（数据流）流入水管，如果超过水管的承受能力，水管就会被撑爆（丢包）。
发送方掩护一个拥塞窗口 cwnd（congestion window） 的变量，调节所要发送数据的量。
什么是拥塞窗⼝？和发送窗⼝有什么关系呢？
拥塞窗⼝ cwnd 是发送⽅掩护的⼀个状态变量，它会根据⽹络的拥塞程度动态变革。
发送窗⼝ swnd 和吸收窗⼝ rwnd 是约即是的关系，那么由于加⼊了拥塞窗⼝的观点后，此时发送窗⼝的值 swnd = min(cwnd, rwnd)，也便是取拥塞窗⼝和吸收窗⼝中的最⼩值。
拥塞窗⼝ cwnd 变革的规则：
只要⽹络中没有涌现拥塞， cwnd 就会增⼤但如果⽹络中涌现了拥塞， cwnd 就会减小拥塞掌握有哪些常用算法？
慢启动慢启动算法，逐步启动。
它表示 TCP 建立连接完成后，一开始不要发送大量的数据，而是先探测一下网络的拥塞程度。由小到大逐渐增加拥塞窗口的大小，如果没有涌现丢包，每收到一个 ACK，就将拥塞窗口 cwnd 的大小加 1（单位是 MSS）。每轮次发送窗口增加一倍，呈指数增长，如果涌现丢包，拥塞窗口就减半，进入拥塞避免阶段。
举个例子：
连接建⽴完成后，⼀开始初始化 cwnd = 1 ，表示可以传⼀个 MSS ⼤⼩的数据。当收到⼀个 ACK 确认应答后，cwnd 增加 1，于是⼀次性能够发送 2 个。当收到 2 个 ACK 确认应答后， cwnd 增加 2，于是就能⽐之前多发送 2 个，以是这⼀次能够发送 4 个。当这 4 个 ACK 确认到来的时候，每个确认 cwnd 增加 1， 4 个确认 cwnd 增加 4，于是就能⽐之前多发送 4 个，以是这⼀次能够发送 8 个。发送包的个数是呈指数性增⻓的。
为了防止 cwnd 增长过大而引起网络拥塞，还需设置一个慢启动阀值 ssthresh（slow start threshold）的状态变量。当 cwnd 到达该阀值后，就彷佛水管被关小了水龙头一样，减少了拥塞状态。即当 cwnd > ssthresh 时，进入拥塞避免算法。
拥塞避免一样平常来说，慢启动阀值 ssthresh 的大小是 65535 字节，cwnd 到达慢启动阀值后
每收到一个 ACK 时，cwnd = cwnd + 1/cwnd当每过一个 RTT 时，cwnd = cwnd + 1显然这是一个线性上升的算法，可以避免发送过快导致网络涌现拥塞问题。
接着上面慢启动的例子，假定 ssthresh 为 8：
当 8 个 ACK 确认应答到来时，每个确认增加 1/8，8 个 ACK 确认后 cwnd ⼀共增加 1，于是这⼀次能够发送 9 个 MSS ⼤⼩的数据，变成了线性增⻓。拥塞发生当网络拥塞发生丢包时，会有两种情形：
RTO 超时重传快速重传如果是发生了RTO 超时重传，就会利用「拥塞发生」算法
慢启动阀值 sshthresh = cwnd/2cwnd 重置为 1进入新的慢启动过程这真的是辛辛劳苦几十年，一朝回到解放前。实在还有更好的处理办法，便是「快速重传」。当发送方收到 3 个连续的重复 ACK 时，就会快速地重传，不必等待 RTO超时 再重传。
发⽣「快速重传」的拥塞发⽣算法：
拥塞窗口大小 cwnd = cwnd/2慢启动阀值 ssthresh = cwnd进入快速规复算法快速规复快速重传和快速规复算法一样平常是同时利用的。快速规复算法认为，还能收到 3 个重复的 ACK，解释网络也没有那么糟糕，以是没必要像 RTO超时重传 那样强烈。
正如前面所说的，进入快速规复之前，cwnd 和 sshthresh 已被更新：
cwnd = cwnd/2sshthresh = cwnd然后，真正进入「快速规复」算法：
cwnd = sshthresh + 3重传重复的那几个 ACK（即丢失的那几个数据包）如果再收到重复的 ACK，那么 cwnd = cwnd +1如果收到新数据的 ACK 后，cwnd = sshthresh。由于收到新数据的 ACK，表明规复过程已经结束，可以再次进入「拥塞避免」算法了。32.说说 TCP 的重传机制？重传包括：超时重传、快速重传、带选择确认的重传（SACK）、重复 SACK 四种。
超时重传超时重传，是 TCP 协议担保数据可靠性的另一个主要机制，其事理是在发送某一个数据往后就开启一个重传计时器，在一定韶光内如果没有收到发送的数据报的 ACK 报文，那么就重新发送数据，直到收到 ACK 报文为止。
超时时间该当设置为多少得当呢？
RTT 便是数据完备发送完，到收到确认旗子暗记的韶光，即数据包的一次来回韶光。
超时重传韶光，便是 RTO（Retransmission Timeout)。那么，RTO 该当设置多大呢？
如果 RTO 设置很大，等了良久都没重发，这样肯定弗成。如果 RTO 设置很小，那很可能数据都没有丢失，就开始重发了，这将会导致网络壅塞，从而发生恶性循环，导致更多的超时涌现。一样平常来说，RTO 略微大于 RTT，效果是最佳的。
超时重传并不是十分完美的重传方案，它有这些缺陷：
当一个报文丢失时，会等待一定的超时周期，才重传分组，增加了端到真个时延。当一个报文丢失时，在其等待超时的过程中，可能会涌现这种情形：其后面的报文段已经被吸收方吸收了但却迟迟得不到确认，发送方会认为其后面的报文段也丢失了，从而引起不必要的重传，既摧残浪费蹂躏资源也摧残浪费蹂躏韶光。快速重传快速重传可以用来办理超时重发的韶光等待问题。
它不以韶光驱动，而因此数据驱动。它是基于吸收方的反馈信息来引发重传的。
快速重传的流程如下：
发送方发送了 1，2，3，4，5，6 份数据:
第一份 Seq=1 先送到了，于是 ACK 回2；第二份 Seq=2 也送到了，于是 ACK 回3；第三份 Seq=3 由于网络等某些缘故原由，没送到；第四份 Seq=4 送到了，但是由于 Seq=3 没收到。因此 ACK 还是回3；后面的 Seq=5，6 也送到了，ACK 还是回答3，由于 Seq=3 没有收到。发送方连续收到三个重复冗余的 ACK=3 的确认（实在是4个哈，但是由于前面的一个是正常的ACK，后面三个才是重复冗余的），于是知道哪个报文段在传输过程中丢失了；发送方就在重传定时器过期之前，重传该报文段。末了，吸收方收到了 Seq=3，此时由于 Seq=4，5，6 都收到了，于是它回 ACK=7。快速重传机制也有缺点：发送方并不知道到底是哪个报文丢失了，到底该重传多少个数据包？
是只重传 Seq=3 ？还是重传 Seq=3、Seq=4、Seq=5、Seq=6 呢？由于发送方并不清楚这三个连续的 ACK=3 是谁传回来的。
带选择确认的重传（SACK）为理解决该当重传多少个包的问题? TCP 供应了带选择确认的重传（即 SACK，Selective Acknowledgment）。
SACK 机制便是，在快速重传的根本上，吸收方返回最近收到报文段的序列号范围，这样发送方就知道吸收方哪些数据包是没收到的。这样就很清楚该当重传哪些数据包。
如上图中，发送⽅收到了三次同样的 ACK 确认报⽂，于是就会触发「快速重传」机制，通过 SACK 信息创造只有 200~299 这段数据丢失，则重发时，就只选择了这个 TCP 段进⾏重发。
重复 SACK（D-SACK）D-SACK，英文是 Duplicate SACK，是在 SACK 的根本上做了一些扩展，紧张用来见告发送方，有哪些数据包，自己重复接管了。
D-SACK 的目的是帮助发送方判断，是否发生了包失落序、ACK 丢失、包重复或伪重传。让 TCP 可以更好的做网络流控。
例如 ACK 丢包导致的数据包重复：
吸收⽅发给发送⽅的两个 ACK 确认应答都丢失了，以是发送⽅超时后，重传第⼀个数据包（3000 ~ 3499）吸收⽅创造数据是重复收到的，于是回了⼀个 SACK = 3000~3500，见告「发送⽅」 3000~3500的数据早已被吸收了，由于 ACK 都到 4000 了，意味着 4000 之前的所有数据都已经收到了，以是这个 SACK 就代表着 D-SACK 。这样发送⽅就知道了，数据并没有丢，而是吸收⽅的 ACK 确认报⽂丢了。33.说说 TCP 的粘包和拆包？
什么是 TCP 粘包和拆包？
TCP 是面向字节流，没有界线的一串数据。TCP 底层并不理解上层业务数据的详细含义，它会根据 TCP 缓冲区的实际情形进行包的划分，以是在业务上认为，一个完全的包可能会被 TCP 拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包进行发送，这便是所谓的 TCP 粘包和拆包问题。
为什么会产生粘包和拆包呢?
要发送的数据小于 TCP 发送缓冲区的大小，TCP 将多次写入缓冲区的数据一次性发送出去，将会发生粘包；吸收方的运用层没有及时读取吸收缓冲区的数据，将会发生粘包；要发送的数据大于 TCP 发送缓冲区剩余空间的大小，将会发生拆包；待发送的数据大于 MSS（最大报文长度），TCP 在传输前将会进行拆包。即 TCP报文长度 - TCP头部长度 > MSS。办理方案：
发送方给每个数据包添加包首部，首部中该当至少包含数据包的长度，这样吸收方在收到数据后，通过读取包首部的长度字段，便知道每一个数据包的实际长度了。发送方将每个数据包封装为固定长度（不足的可以通过补0添补），这样吸收方每次从吸收缓冲区中读取固定长度的数据，就自然而然的把每个数据包拆分开来。可以在数据包之间设置边界，如添加分外符号，这样吸收方通过这个边界就可以将不同的数据包拆分开来。
