1.三次握手和四次挥手

1. 三次握手

• 第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。
• 第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。
• 第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。

image

2. 四次挥手

• 第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
• 第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。此时TCP链接处于半关闭状态，即客户端已经没有要发送的数据了，但服务端若发送数据，则客户端仍要接收。
• 第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。

• 第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。

  
  
  image

2.为什么要三次握手

“三次握手” 的目的是为了防止已失效的链接请求报文突然又传送到了服务端，因而产生错误。

• 正常的情况：A 发出连接请求，但因连接请求报文丢失而未收到确认，于是 A 再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。A 共发送了两个连接请求报文段，其中第一个丢失，第二个到达了 B。没有 “已失效的连接请求报文段”。

• 现假定出现了一种异常情况：即 A 发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 B。本来这是一个早已失效的报文段。但 B 收到此失效的连接请求报文段后，就误认为是 A 再次发出的一个新的连接请求。于是就向 A 发出确认报文段，同意建立连接。(滞留后到达服务端的报文会引起服务端的响应，此时客户端已经结束了连接不再发送资源，服务端发出信息后，连接确认。客户端却不发送任何数据，导致连接建立后浪费服务端资源)
  假设不采用“三次握手”，那么只要 B 发出确认，新的连接就建立了。由于现在 A 并没有发出建立连接的请求，因此不会理睬 B 的确认，也不会向 B 发送数据。但 B 却以为新的运输连接已经建立，并一直等待 A 发来数据。这样，B 的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。

3.为什么要四次挥手？

TCP 协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP 是全双工模式，这就意味着，当 A 向 B 发出 FIN 报文段时，只是表示 A 已经没有数据要发送了，而此时 A 还是能够接受到来自 B 发出的数据；B 向 A 发出 ACK 报文段也只是告诉 A ，它自己知道 A 没有数据要发了，但 B 还是能够向 A 发送数据。

4.HTTP

HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写,是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）。

1. 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
2. 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
3. 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
4. 无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
5. 支持B/S及C/S模式。
   请求步骤:

1、客户端连接到Web服务器

一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。例如，http://www.oakcms.cn。

2、发送HTTP请求

通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成。

3、服务器接受请求并返回HTTP响应

Web服务器解析请求，定位请求资源。服务器将资源复本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。

4、释放连接TCP连接

若connection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求;

5、客户端浏览器解析HTML内容

客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。
Content-Type:
请求的与实体对应的MIME信息
Content-Type: application/x-www-form-urlencoded
例如： Content-Type: text/html;charset:utf-8;

• application/json ： JSON数据格式
• text/html ： HTML格式
• text/plain ：纯文本格式

image.png

• 在HTTP/1.0中，默认使用的是短连接。也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的 Web页中包含有其他的Web资源，如JavaScript文件、图像文件、CSS文件等；当浏览器每遇到这样一个Web资源，就会建立一个HTTP会话。
  但从 HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头有加入这行代码：
  Connection:keep-alive
• 在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接要客户端和服务端都支持长连接。

5.计算机网络中五层 tcp属于那一层 tcp具体实施

image.png

image.png

• TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接。
• TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付。
• Tcp通过校验和，重传控制，序号标识，滑动窗口、确认应答实现可靠传输。如丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。
• UDP具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性有较高的通信或广播通信。
• 每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信。
• TCP对系统资源要求较多，UDP对系统资源要求较少。
• UDP 是一种面向无连接，且不可靠的协议，在通信过程中，它并不像 TCP 那样需要先建立一个连接，只要（目的地址，端口号，源地址，端口号）确定了，就可以直接发送信息报文，并且不需要确保服务端一定能收到或收到完整的数据。它仅仅提供了校验和机制来保障一个报文是否完整，若校验失败，则直接丢弃报文，不做任何处理。

6.Http与Https

答：Http协议运行在TCP之上，明文传输，客户端与服务器端都无法验证对方的身份；Https是身披SSL(Secure Socket Layer)外壳的Http，运行于SSL上，SSL运行于TCP之上，是添加了加密和认证机制的HTTP。二者之间存在如下不同：

• 端口不同：Http与Http使用不同的连接方式，用的端口也不一样，前者是80，后者是443；
• 资源消耗：和HTTP通信相比，Https通信会由于加减密处理消耗更多的CPU和内存资源；
• 开销：Https通信需要证书，而证书一般需要向认证机构购买；Https的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。

7.TCP 的拥塞避免机制

拥塞：对资源的需求超过了可用的资源。网络中许多资源同时供应不足，整个网络的吞吐量随之负荷的增大而下降。对资源要求的总和>可用资源(通信流量>带宽)
拥塞控制：防止过多的数据注入到网络中，使得网络中的路由器或链路不致过载(数据包太多，路由器难以处理出现丢包)。
拥塞控制用于避免出现死锁状况，从而达到实际拥塞控制的状况(路由器采用)

image.png

拥塞控制的方法：

1. 慢开始 + 拥塞避免：

• 慢开始：发送方维持拥塞窗口cwnd(congestion window)，cwnd先从1开始慢慢加大，每经过一个RTT且返回正常cwnd会成倍增长，发送速度越来越快。当达到了慢开始门限值，正常的情况下下一轮cwnd+1(加法增大)。在出现丢包时(网络拥塞)会计算一个新的慢开始门限(这个值等于出现丢包时的cwnd/2)。下一轮cwnd的值会从1指数增长到新的慢开始门限，然后进行线性增长。
• 拥塞避免：拥塞避免算法让拥塞窗口缓慢增长，在cwnd超过慢开始门限后(ssthresh)每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍，这样拥塞窗口按线性规律缓慢增长，直到出现拥塞现象后cwnd置1再次慢开始。
  
  image

2. 快重传 + 快恢复：

• 快重传：在以前的情况下B端会累计确认,即收到一组数据包后在进行确认。在得知一组数据包中的其中一个丢失，B端会连发三个确认报文(含有需要重传的序号)让A端重新发送这个丢失的报文而不是等到接收完一组后再发确认信息要求重传。发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。在出现丢包的情况下网络可能快拥塞了，此时接收端即时发送三个含序号的确认包(连着收到三个确认说明此刻未拥塞但可能会进入拥塞状态)。
• 快恢复：快重传配合使用的还有快恢复算法，当发送方连续收到三个重复确认时，就立刻把ssthresh门限减半，但是接下去并不执行慢开始算法：因为如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。就会把cwnd设置为慢开始门限的大小，从新的慢开始门限值进行线性增加。

发送窗口上限值 =Min[rwnd,cwnd],由接收窗口控制与发送出窗口的拥塞窗口指定。

image

8.浏览器中输入：“www.xxx.com” 之后都发生了什么？请详细阐述。

1. 由域名→IP地址 寻找IP地址的过程依次经过了浏览器缓存、系统缓存、hosts文件、路由器缓存、 递归搜索根域名服务器。
2. 建立TCP/IP连接（三次握手具体过程）
3. 由浏览器发送一个HTTP请求
4. 经过路由器的转发，通过服务器的防火墙，该HTTP请求到达了服务器
5. 服务器处理该HTTP请求，返回一个HTML文件
6. 浏览器解析该HTML文件，并且显示在浏览器端

9.TCP 协议如何来保证传输的可靠性

TCP 提供一种面向连接的、可靠的字节流服务。其中，面向连接意味着两个使用 TCP 的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个 TCP 连接。在一个 TCP 连接中，仅有两方进行彼此通信；而字节流服务意味着两个应用程序通过 TCP 链接交换 8 bit 字节构成的字节流，TCP 不在字节流中插入记录标识符。

• 停止等待协议：(正常情况)发送数据包后必须等待确认才会选择继续让其发送，否则等待。(超时重传)发出一个数据包后等待一个RTT时间(往返)后若没有收到确认信息，将重新发送这个报文(默认丢失,不确认就重传)。(确认包丢失)A端发M1B端收到后,B端发给A端的确认包丢失,A端会认为超时重传会再发一次M1，此时B端不接受M1但会再发送确认包信息给A端。(确认包迟到)B端发给A端的确认包迟到，A端默认丢失超时重传，B端接收后再次发送确认包，A端收到迟到的确认包时什么也不做。(只有收到确认信息才继续，否则重发,在不可靠的网络上实现可靠的TCP通信ARQ)。
• 连续ARQ(发送窗口)：发送方维持发送窗口，可以一次性发送窗口大小这么多个数据包然后等待确认报文，得到确认后窗口滑动发送新的字节流报文。互相根据对方的接收缓存设置(65535)发送窗口大小(1460)
• 滑动窗口：发送方和接收方都有缓冲区，发送时会维护一个以字节为单位的滑动窗口，如果收到确认后窗口就会滑动，发送缓冲区会丢弃已发送的字节，B端发送确认报文后，窗口移动(确认报文含有下一步该发哪一个字节组成的报文)。接收窗口先移动，然后发送端口移动。窗口到底后循环使用
• 数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时TCP发送数据端超时后会重发数据。TCP首部中的确认序号表示已成功收到字节，但还不包括确认序号所指的字节。希望下一次能收到确认序号所指的字节。 发送端初始时序号为1，同时会发送下一次将会发送的起始序号，接收端接收后返回确认同时包含发送端下一次发送的起始序号。若返回的是确认信息(已发送的包都没必要重传)则发送端窗口移动。
• 对丢失的数据包段发送选择型确认：若A端发送的数据包有丢失的情况,B端会返回确认包(SAK选择型确认)会告诉A端哪个序号部分的丢失，A端会重新发这一个数据包，然后发送窗口往前移动
• 丢弃重复数据：对于重复数据，能够丢弃重复数据；
• 应答机制：当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；
• 超时重发：当TCP发出一个段后，它启动一个计时器，等待接收端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段，时间稍大于RTT
• 流量控制：TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。对于发送端A端与接收端B端，A有发送缓存而B有接收缓存，要发送的数据先放到A的发送缓存，建立会话时B端设置自己的接收窗口(发送Ack，rwnd(receive window)=10(字节))。A根据此设置发送窗口，此时可以连续发送数据包。B端会根据自己的情况回复成功报文(包括rwnd)，若B端压力过大rwnd的值会缩小，待B端处理后rwnd的值再进行扩展，若含有rwnd的包遗失，A端会定时发包询问。通过接收端告诉发送端接收窗口的大小来防止缓冲区溢出。

10.TCP与UDP分别对应的常用协议。

TCP对应协议

• FTP：21端口用于连接，20端口用于传输数据。定义了文件传输协议，使用21端口。常说某某计算机开了FTP服务便是启动了文件传输服务。下载文件，上传主页，都要用到FTP服务。我们平常下载文件时，会遇到下载到99%时，文件不完成，不能成功的下载。
  其实是因为文件下载完毕后，还要在21端口再行进行用户认证，而下载文件的时间如果过长，客户机与服务器的21端口的连接会被服务器认为是超时连接而中断掉，就是这个原因。解决方法就是设置21端口的响应时间。
• SMTP：定义了简单邮件传送协议，现在很多邮件服务器都用的是这个协议，用于发送邮件。如常见的免费邮件服务中用的就是这个邮件服务端口，所以在电子邮件设置-中常看到有这么SMTP端口设置这个栏，服务器开放的是25号端口。
• POP3：它是和SMTP对应，POP3用于接收邮件。通常情况下，POP3协议所用的是110端口。也是说，只要你有相应的使用POP3协议的程序（例如Fo-xmail或Outlook），就可以不以Web方式登陆进邮箱界面，直接用邮件程序就可以收到邮件（如是163邮箱就没有必要先进入网易网站，再进入自己的邮-箱来收信）。

UDP对应协议

• DNS：用于域名解析服务，将域名地址转换为IP地址。DNS用的是53号端口。
• SNMP：简单网络管理协议，使用161号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。
• TFTP(Trival File Transfer Protocal)：简单文件传输协议，该协议在熟知端口69上使用UDP服务

作者：我没有三颗心脏
链接：https://www.jianshu.com/p/210f85108c52
来源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。