《计算机网络常见问题》

四次挥手中TIME_WAIT出现的时候以及作用。

主动断开连接的一方收到对端的连接释放报文段就进入TIME_WAIT状态。假设A是主动断开的一方，另一方是B

作用：

（1）保证A发送的最后一个确认报文段可以到达B。因为这个报文段可能会丢失，如果A不等待一段时间在收到B的超时重传报文段后再发送确认，B就无法进入CLOSED状态。一般是，如果报文段丢失，那么在2MSL时间段内A就会收到超时重传报文段，重新发送确认。然后再重启2MSL计时器。直至A，B都进入CLOSED状态。

（2）防止已经失效的连接请求报文段再次出现在下次连接中。A发送完最后一个确认报文段之后，在经过2MSL之后，就可以使本连接持续时间内所产生的所有报文段都从网络中消失。

为什么建立连接是三次握手，而关闭连接需要四次挥手

1 服务器在LINSTEN状态下，收到客户端连接建立请求的报文，从而得知客户端的序列号之后，需要告知服务器自己收到了连接请求并同意建立连接，同时还需要告知客户端自己的序列号，然而ACK和SYN是可以放在同一报文中的。

2 关闭连接时，当B收到A的FIN报文段时，仅仅表示A数据传送发送完毕了，但A还可以接收数据，这时B是否也同时断开连接即关闭数据发送通道，需要上层应用决定，因此B方的连接断开请求报文和对A的断开确认报文段是分开发送的。

序列号的作用

序列号的作用是使得一个TCP接收端可丢弃重复的报文段，记录以乱序到达的报文段。因为TCP使用IP来传输报文段，而IP并不提供重复消除或者保证报文段按照次序正确到达的功能。另外，TCP是一种字节流协议，绝不会以乱序给上层程序发送数据。因此TCP接收端会被迫先保持大序列号的数据不交给应用程序，直到缺失的小序列号的报文段被填满。

三次握手四次挥手的过程

三次握手:

（1）A（客户端进程）和B（服务器进程）先创建传输控制模块TCB，服务器进程进入收听（LISTEN）状态。等待客户的连接请求。

（2）A向B发送连接请求报文段，把首部中的同步位置1（SYN=1），同时选择一个初始序列号seq=x，A进入SYN-SENT（同步已发送）状态

（3）B收到连接请求之后，，如果同意建立连接，就向A发送确认，在确认报文段中把SYN和ACK都置1，确认号ack=x+1，同时也为自己选取一个序列号seq=y。B进入SYN-RCVD(同步收到状态)。

（4）A收到B的确认之后，还要给B发送确认，把ACK置1，确认号ack=y+1，序列号为x+1。这时A进入ESTABLISHED(已建立连接)状态，B收到A的确认之后也会进入连接状态。

四次挥手：

 为什么建立连接需要三次握手，而不是二次或者四次？

首先三次握手的过程是：A向B发送连接请求报文段，B收到之后会发送确认报文段，A在收到B的确认之后还会再发送一次确认。

A再次发送一次报文段的目的是为了防止已经失效的连接请求报文段突然又传到B，因而产生错误。

想象下这种情况，A发送了一个连接请求报文段给B，但是滞留在网络中某个节点上，A在计时器时间内收不到B的确认会超时重传报文段，当A与B建立了连接完成了数据传输并释放连接后，滞留在网络中的报文段又发送给了B，B以为A又发送了连接请求，随即发送确认，这个时候如果不采用第三次握手，由于A没有发送链接请求不会理会B的确认，而B以为链接已经建立，会一直等待A发送数据，浪费网络资源。

实际上对于三次握手来说，我们只可以保证三次握手之后，客户和服务器之间可以建立连接，传输数据，对于其它的一些情况，我们是不能保证的，我们不能保证第二次握手，客户一定能收到服务器的 ACK 和 SYN，也不能确定第三次握手服务器一定能收到客户的 ACK，但是完全可靠的通信协议是根本不存在的，我们的任何通信协议都是在接受这样的现实情况之上进行的，所以从这个角度理解，无论是四次还是五次或是更多次都是徒劳的。

TCP/UDP的区别

（1）TCP是面向连接的，在传输数据之前必须先建立连接，传送完毕之后，必须释放连接（HTTP）。而UDP是无连接的，发送数据前不需要建立连接，减少了开销和发送数据之前的时延。（DNS）

（2）TCP提供可靠的服务。通过TCP连接传送的数据，无差错，不重复，不丢失，无乱序。而UDP使用尽最大努力交付。

（3）TCP是面向字节流的，即把应用程序交付下来的数据看为仅仅是一连串的无结构的字节流。而UDP是面向报文的。UDP对于接收到的报文，不拆分，不合并，而是保留这些报文的边界。

（4）UDP没有拥塞控制，因此网络中出现的拥塞不会使源主机的发送速率降低。而TCP拥有拥塞控制机制

（5）TCP每一条连接都是端到端的；而UDP可支持一对一，一对多，多对一，多对多的交互通信。

（6）UDP的首部开销比较小，只有8个字节，比TCP的20个字节首部要短。

GET/POST的区别

GET和POST两种基本请求方法的区别 - 在途中# - 博客园

GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。

（1）从意义上来说，GET主要用于信息获取，向特定的资源发出请求。而POST主要用于向指定资源提交数据（如提交表单或上传文件），可能会修改服务器上的资源。

（2）从具体数据传送形式来说，GET请求的数据会附加到URL之后（把数据放在HTTP的协议头），以？分割URL和传输数据，参数之间用&连接。而POST会把提交的数据放到HTTP的请求报文的内部即实体主体，比GET较为安全。

（3）浏览器多数情况下会对GET的URL长度进行限制，虽然本身HTTP协议没有对URL长度进行限制，但如果过长对服务器会是一种负担。而POST没有限制。

（4）GET在浏览器中回退时是无害的，而POST会再次提交请求，可能会修改数据。

（5）GET请求会被浏览器主动缓存，而POST不会，除非手动设置

（6）GET只接受ASCII字符的参数 的数据类型，而POST没有限制。

（7）GET产生一个TCP数据包，而POST会产生2个TCP数据包。因为GET将参数或数据放在HTTP协议头中进行发送，所以只产生一个TCP报文段，服务器响应200，而POST则先发送协议头部，服务器响应100，浏览器再次发送数据，服务器响应200，因此需要2个数据包。

POST/PUT：

HTTP协议中PUT和POST使用区别_其实并不难,是你太悲观-CSDN博客_post和put的区别

PUT 幂等

http1.0/http1.1的区别

（1）是否默认长连接：

HTTP1.0默认浏览器和服务器只保持短暂的连接，浏览器每次请求都需要与服务器建立一个 TCP 连接，服务器完成请求处理后立即断开TCP 连接，服务器不跟踪每个客户也不记录过去的请求。

而 HTTP1.1 默认支持长连接，在一个 TCP 连接上可以传送多个 HTTP 请求和响应，减少了建立和关闭连接的消耗和延迟。HTTP1.1 还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能区分出每次请求的响应内容。

（2）HTTP1.1增加了host头域。

在 HTTP1.0 中认为每台服务器都绑定唯一的 IP 地址，因此，请求消息中的 URL 并没有传递主机名。但随着虚拟主机技术的发展，在一台物理服务器上可以有多个虚拟主机，并且它们共享一个 IP 地址。HTTP1.1 的请求消息和响应消息都支持 Host 头域，且请求消息中如果没有 Host 头域会报告一个错误（400 Bad Request）。HTTP1.1 实现了在一台 web 服务器上可以在同一个 IP 地址和端口号上使用不同的主机名来创建多个虚拟 web 站点。

（3）HTTP1.1加入了一个新的状态码100（Continue）

客户端先发送一个只带头域的请求，如果服务器因为权限拒绝了请求，就回送响应码401（Unauthorized）；如果服务器接收此请求就回送状态码 100，客户端就可以继续发送带实体的完整请求了。100 (Continue) 状态代码的使用，允许客户端在发request消息body之前先用request header试探一下server，看server要不要接收request body，再决定要不要发request body。

（4）带宽优化

HTTP1.0 中存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象传送过来了。HTTP1.1 中在请求消息中引入了 range 头域，它允许只请求资源的某个部分。

http通信存在的问题

（1）容易被监听 ：http通信都是明文，数据在客户端与服务器通信过程中，任何一点都可能被劫持。比如，发送了银行卡号和密码，hacker劫取到数据，就能看到卡号和密码，这是很危险的

（2）被伪装 ：http通信时，无法保证通行双方是合法的，通信方可能是伪装的。比如你请求www.taobao.com,你怎么知道返回的数据就是来自淘宝，中间人可能返回数据伪装成淘宝。

（3）被篡改 ：hacker中间篡改数据后，接收方并不知道数据已经被更改。

https解决的问题

https很好的解决了http的三个缺点（被监听、被篡改、被伪装），https不是一种新的协议，它是http+SSL(TLS)的结合体，SSL是一种独立协议，所以其它协议比如smtp等也可以跟ssl结合。https改变了通信方式，它由以前的http—–>tcp，改为http——>SSL—–>tcp；https采用了对称密钥加密+非对称密钥加密的方式

（1）防监听 ：数据是加密的，所以监听得到的数据是密文，hacker看不懂。

（2）防伪装 ：伪装分为客户端伪装和服务器伪装，通信双方携带证书，证书相当于身份证，有证书就认为合法，没有证书就认为非法，证书由第三方颁布，很难伪造

（3）防篡改 ：https对数据做了摘要，篡改数据会被感知到。hacker即使从中改了数据也白搭。

http和https的区别

/*SSL( 安全套接层),及其继任者传输层安全（TLS）是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层对网络连接进行加密。

提供的服务：1）认证用户和服务器，确保数据发送到正确的客户机和服务器；2）加密数据以防止数据中途被窃取；3）维护数据的完整性，确保数据在传输过程中不被改变。*/

（1）HTTP 是直接在客户端与服务器之间建立 TCP 连接，默认使用 80 端口，使用明文在网络中传输通信，通信结束后，断开 TCP 连接。

（2） HTTPS 则是具有安全性的 ssl 加密传输协议，起初需要建立 SSL安全连接，默认使用 443 端口，在网络中传输的内容也是经过加密的。

（1）客户端发起HTTPS请求，首先连接到服务器的443端口。

（2）服务器向客户端返回数字证书和公开密钥，公开密钥作为数字证书的一部分，证书中还包括其它信息，即证书颁发机制，过期时间等。

（3）客户端解析证书，验证公钥是否有效，如果有效，就生成共享密钥，并通过非对称加密将其传送给服务器。

（4）服务器使用私钥解密数据，并使用收到的共享密钥通过对称加密，将数据发送到客户端。

（5）客户端使用共享密钥解密数据。SSL连接建立。

因为共享密钥是通过非对称加密传输的，其明文没有在网络中出现过，而且之后每次传输数据都是利用共享密钥进行加密解密，攻击者无法窃取。

http升级为https需要做什么。

服务器需要支持https协议，自己申请证书或者向组织机构申请证书。

https的缺点 

https保证了通信的安全，但带来了加密解密消耗计算机cpu资源的问题 ，不过，有专门的https加解密硬件服务器

各大互联网公司，百度、淘宝、支付宝、知乎都使用https协议，为什么？ 

支付宝涉及到金融，所以出于安全考虑采用https这个，可以理解，为什么百度、知乎等也采用这种方式？为了防止运营商劫持！http通信时，运营商在数据中插入各种广告，用户看到后，怒火发到互联网公司，其实这些坏事都是运营商(移动、联通、电信)干的,用了https，运营商就没法插播广告篡改数据了。

对称密钥（加密）和非对称密钥（加密）

（1）对称密钥（私钥加密）

信息的发送方和接受方用一个密钥去加密和解密数据。最大的优势就是加密解密速度快，适合于对大数据量进行加密，对称密钥的一大缺点是密钥的管理与分配，也就是说，如何安全的把密钥发送给需要解密的人的手里。在发送密钥的过程中，密钥有很大风险会被黑客们拦截。对称密钥通常使用的是相对较小的密钥，一般小于 256bit，因为密钥越大，加密越强越难破解，但同时加密和解密的过程也变的更慢，所以密钥的大小不适合过大也不适合过小。

（2）非对称密钥（公钥加密）

它使用了一对密钥，公钥（public key）和私钥（private key）。私钥只能由一方安全保管，不能外泄，而公钥则可以发送给任何请求它的人。非对称密钥使用这对密钥中的一个进行加密，而解密则需要另一个密钥。

目前最常用的非对称加密算法是 RSA 算法，公钥机制灵活，但是加密和解密的过程比对称密钥加密要慢很多。

（3）虽然非对称加密很安全，但是和对称加密相比，非常慢，所以我们还是要使用对称加密来对消息进行加密传送，但是对称加密所用的密钥我们可以通过非对称加密的方式发送出去。

网页解析的过程

（1）用户输入URL，浏览器根据URL中的域名通过DNS（DNS端口号是53，HTTP的端口号是80）查找服务器对应的IP地址。

（2）浏览器通过DNS解析出来的IP地址，会以一个随机端口（1024-65535）向web服务器的的80端口发起TCP连接请求，通过TCP三次握手与web服务器建立连接。

（3）浏览器向web服务器发送http请求报文（请求行，请求头，请求数据）

（4）服务器做出响应，返回响应数据传送给客户端。响应报文包括（状态行，响应头，响应数据）这时web服务器会根据HTTP请求头中的connection字段值来决定是否关闭TCP连接，当为keep-alive时，web服务器不会立即关闭此连接，该连接则会被保持一段时间，在该时间内可以继续接收请求；如果 Connection 为 close，则服务器主动关闭 TCP 连接，客户端被动关闭连接。

（5）客户端浏览器首先解析状态行，根据状态码确定请求是否成功，之后解析响应头和 HTML 内容，根据HTML 的语法对其进行格式化，并在浏览器窗口中显示。

Session与Cookie的区别

cookie 和session 的区别详解 - 施杨 - 博客园

UDP如何实现可靠传输

UDP如何实现可靠传输 - 简书

udp如何实现可靠性传输？_3-Number-CSDN博客_udp如何实现可靠传输

MSS和MTU

mtu是网络传输报文包长度。 mss是网络传输数据的长度。

 mss加包头数据就等于mtu. 简单说拿TCP包做例子。 报文传输1400字节的数据的话，那么mss就是1400，再加上20字节IP包头，20字节tcp包头，那么mtu就是1400+20+20. 当然传输的时候其他的协议还要加些包头在前面，总之mtu就是总的最后发出去的报文大小。mss就是你需要发出去的数据大小。

1.MSS: Maxitum Segment Size 最大分段大小

 2.MSS最大传输大小的缩写，是TCP协议里面的一个概念。

3.MSS就是TCP数据包每次能够传输的最大数据分段。为了达到最佳的传输效能TCP协议在建立连接的时候通常要协商双方的MSS值，这个值TCP协议在实现的时候往往用MTU值代替（需要减去IP数据包包头的大小20Bytes和TCP数据段的包头20Bytes）所以往往MSS为1460。通讯双方会根据双方提供的MSS值得最小值确定为这次连接的最大MSS值。

MTU：maximum transmission unit，最大传输单元，由硬件规定，如以太网的MTU为1500字节。

MSS：maximum segment size，最大分节大小，为TCP数据包每次传输的最大数据分段大小，一般由发送端向对端TCP通知对端在每个分节中能发送的最大TCP数据。MSS值为MTU值减去IPv4 Header（20 Byte）和TCP header（20 Byte）得到。

分片：若一IP数据报大小超过相应链路的MTU的时候，IPV4和IPV6都执行分片(fragmentation)，各片段到达目的地前通常不会被重组(re-assembling)。IPV4主机对其产生的数据报执行分片，IPV4路由器对其转发的数据也执行分片。然而IPV6只在数据产生的主机执行分片；IPV6路由器对其转发的数据不执行分片。

例如：一个以太网上的主机和一个令牌环网上的主机间建立连接，其中以太网上主机通告的MSS为1460，令牌环网上主机通告的MSS为4096。观察分组，在两个方向上都找不到大于1460字节的数据，为什么？

        令牌环网上发送到以太网的数据大小不大于1460字节的原因是因为以太网上主要通告的MSS值就为1460个字节，所以令牌环网上发送出去的数据的长度不能够大于MSS值；令牌环网上主机通告的MSS值为4096，也即是说以太网能够发送到令牌环网上的TCP净荷值为4096，但是以太网的MTU值又是由硬件所决定的，最大只支持1500（包括IP头至少20B和TCP头至少20B），为避免分片，因此以太网发送到令牌环网的数据的净荷也为1500-20-20=1460B，所以两个方向的净数据长度不会大于1460字节。

HTTP状态码：共有5大类33种：

（1）1xx 表示通知信息的，如请求收到了或正在处理

（2）表示成功，如接受或知道了

（3）表示重定向，如要完成请求还需要采取进一步的行动。

（4）表示客户的差错，如请求中有错误的语法或不能完成。

（5）表示服务器的差错，如服务器失效无法完成请求。

TCP粘包问题

1 什么是粘包现象

TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。

2 为什么出现粘包现象

（1）发送方原因

我们知道，TCP默认会使用Nagle算法。而Nagle算法主要做两件事：1）只有上一个分组得到确认，才会发送下一个分组；2）收集多个小分组，在一个确认到来时一起发送。

所以，正是Nagle算法造成了发送方有可能造成粘包现象。

（2）接收方原因

TCP接收到分组时，并不会立刻送至应用层处理，或者说，应用层并不一定会立即处理；实际上，TCP将收到的分组保存至接收缓存里，然后应用程序主动从缓存里读收到的分组。这样一来，如果TCP接收分组的速度大于应用程序读分组的速度，多个包就会被存至缓存，应用程序读时，就会读到多个首尾相接粘到一起的包。

3 什么时候需要处理粘包现象

（1）如果发送方发送的多个分组本来就是同一个数据的不同部分，比如一个很大的文件被分成多个分组发送，这时，当然不需要处理粘包的现象；

（2）但如果多个分组本毫不相干，甚至是并列的关系，我们就一定要处理粘包问题了。比如，我当时要接收的每个分组都是一个有固定格式的商品信息，如果不处理粘包问题，每个读进来的分组我只会处理最前边的那个商品，后边的就会被丢弃。这显然不是我要的结果。

4 如何处理粘包现象

（1）发送方

对于发送方造成的粘包现象，我们可以通过关闭Nagle算法来解决，使用TCP_NODELAY选项来关闭Nagle算法。

（2）接收方

遗憾的是TCP并没有处理接收方粘包现象的机制，我们只能在应用层进行处理。

（3）应用层处理

应用层的处理简单易行！并且不仅可以解决接收方造成的粘包问题，还能解决发送方造成的粘包问题。

解决方法就是循环处理：应用程序在处理从缓存读来的分组时，读完一条数据时，就应该循环读下一条数据，直到所有的数据都被处理；但是如何判断每条数据的长度呢？

两种途径：

1）格式化数据：每条数据有固定的格式（开始符、结束符），这种方法简单易行，但选择开始符和结束符的时候一定要注意每条数据的内部一定不能出现开始符或结束符；

2）发送长度：发送每条数据的时候，将数据的长度一并发送，比如可以选择每条数据的前4位是数据的长度，应用层处理时可以根据长度来判断每条数据的开始和结束。

当时在做购物车的时候，我最开始的做法是设置开始符（0x7e）和结束符（0xe7），但在测试大量数据的时候，发现了数据异常。正如我所猜测，在调试过程中发现某些数据内部包含了它们。因为要处理的数据是量非常庞大，为做到万无一失，最后我采用了发送长度的方式。再也没有因为粘包而出过问题。

https://www.cnblogs.com/kex1n/p/6502002.html（推荐博客）

https://www.jianshu.com/p/7947991db5a3（拆包和粘包）