计算机网络总结【一】

1、浏览器中输入URL会发生什么？

• 1、URL解析和DNS查询

  • DNS：将主机名和域名解析成IP地址
  • 首先判断你输入的是一个合法的 URL 还是一个待搜索的关键词，并且根据你输入的内容进行自动完成、字符编码等操作
  • DNS查询：
  • 

• 2、浏览器和服务器建立TCP连接

  • 三次握手，建立TCP连接，形成客户端到服务器端的稳定的通道

• 3、HTTP发送请求

  • http请求包含请求头，也可能包含请求体两部分，请求头中包含我们希望对请求文件的操作的信息，请求体中包含传递给后台的参数

• 4、服务器处理请求并返回 HTTP 报文

  • 服务器收到http请求后，后台开始工作，如负载平衡，跨域等，这里就是后端的工作了。
  • 文件处理完毕，生成响应数据包，响应也包含两部分，响应头和相应体，响应体就是我们所请求的文件。
  • 经过网络传输，文件被下载到本地客户端，客户端开始加载

• 5、浏览器处理请求

  • html页面的解析与渲染

• 6、断开连接：TCP 四次挥手

2、http和https的区别

• 安全性上，HTTPS是安全超文本协议，在HTTP基础上有更强的安全性。简单来说，HTTPS是使用TLS/SSL加密的HTTP协议
• 申请证书上，HTTPS需要使用ca申请证书
• 传输协议上, HTTP是超文本传输协议，明文传输；HTTPS是具有安全性的 SSL 加密传输协议
• 连接方式与端口上，http的连接简单，是无状态的，端口是 80； https 在http的基础上使用了ssl协议进行加密传输，端口是 443
• 参考HTTP和HTTPS的区别

3、GET 和 POST 的区别

    http的四种请求：增、删、改、查：put、delete、post、get

     写的非常好的HTTP和HTTPS的区别

• get 是获取数据、post是修改数据
• GET请求只能进行url编码，而POST支持多种编码方式。
• GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
• GET请求在URL中传送的参数是有长度限制的，而POST没有。
• 对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
• GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
• GET参数通过URL传递，POST放在Request body中。

4、TCP和UDP的区别：

• 1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接
• 2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付。Tcp通过校验和，重传控制，序号标识，滑动窗口、确认应答实现可靠传输。如丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。
• 3、UDP具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性有较高的通信或广播通信。
• 4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
• 5、TCP对系统资源要求较多，UDP对系统资源要求较少

• TCP是面向连接的协议，发送数据前要先建立连接，TCP提供可靠的服务，也就是说，通过TCP连接传输的数据不会丢失，没有重复，并且按顺序到达；

• UDP是无连接的协议，发送数据前不需要建立连接，是没有可靠性；

• TCP通信类似于于要打个电话，接通了，确认身份后，才开始进行通行；

• UDP通信类似于学校广播，靠着广播播报直接进行通信。

• TCP只支持点对点通信，UDP支持一对一、一对多、多对一、多对多；

• TCP是面向字节流的，UDP是面向报文的；
  面向字节流是指发送数据时以字节为单位，一个数据包可以拆分成若干组进行发送，而UDP一个报文只能一次发完。

• TCP首部开销（20字节）比UDP首部开销（8字节）要大

• UDP 的主机不需要维持复杂的连接状态表

什么时候应该使用TCP？

当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，这往往用于一些要求可靠的应用，比如HTTP、HTTPS、FTP等传输文件的协议，POP、SMTP等邮件传输的协议。

什么时候应该使用UDP？
当对网络通讯质量要求不高的时候，要求网络通讯速度能尽量的快，这时就可以使用UDP

UDP相对TCP的优势：

（1）无延时。只要应用进程将数据传递给UDP，UDP就会将此数据打包进UDP报文段并立即传递给网络层。但是TCP可能会因为拥塞阻塞机制阻止运输层TCP发送方，并且一直等待，直到可以发送，这会增加时延。对实时应用，少量数据损耗并不影响，但延时不能太大，这最好使用UDP，如网络电话。
（2）UDP无需连接建立，相比TCP节省了三次握手时间。DNS使用UDP协议，主要是因为UDP不需要建立连接，节省了握手时间，如果运行在TCP上，DNS会很慢。常见使用UDP协议的应用如下：QQ语音、QQ视频、TFTP、DNS

（3）UDP无连接状态，而TCP需要维护连接状态，这包括维持一些参数，因此使用UDP可以使服务器同时支持更多用户。
（4）分组开销小，UDP使用8字节首部开销（各两字节：源端口号、目的端口号、长度、检验和），TCP使用20字节首部开销。

5、TCP三次握手

• 第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN©。此时客户端处于 SYN_SEND 状态。

  首部的同步位SYN=1，初始序号seq=x，SYN=1的报文段不能携带数据，但要消耗掉一个序号。

  第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)。同时会把客户端的 ISN + 1 作为ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_REVD 的状态。

  在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y。

  第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。

  确认报文段ACK=1，确认号ack=y+1，序号seq=x+1（初始为seq=x，第二个报文段所以要+1），ACK报文段可以携带数据，不携带数据则不消耗序号。

  发送第一个SYN的一端将执行主动打开（active open），接收这个SYN并发回下一个SYN的另一端执行被动打开（passive open）。

  在socket编程中，客户端执行connect()时，将触发三次握手。

• 

• 5.1 为什么需要三次握手，两次不行吗？

  弄清这个问题，我们需要先弄明白三次握手的目的是什么，能不能只用两次握手来达到同样的目的。

  第一次握手：客户端发送网络包，服务端收到了。

  这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。

  第二次握手：服务端发包，客户端收到了。

  这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。

  第三次握手：客户端发包，服务端收到了。

  这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

  因此，需要三次握手才能确认双方的接收与发送能力是否正常。

6、四次挥手

• 建立一个连接需要三次握手，而终止一个连接要经过四次挥手（也有将四次挥手叫做四次握手的）。这由TCP的半关闭（half-close）造成的。所谓的半关闭，其实就是TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。

  TCP 的连接的拆除需要发送四个包，因此称为四次挥手(Four-way handshake)，客户端或服务器均可主动发起挥手动作。

  刚开始双方都处于 ESTABLISHED 状态，假如是客户端先发起关闭请求。四次挥手的过程如下：

  第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。

  即发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN_WAIT1（终止等待1）状态，等待服务端的确认。

  第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。

  即服务端收到连接释放报文段后即发出确认报文段（ACK=1，确认号ack=u+1，序号seq=v），服务端进入CLOSE_WAIT（关闭等待）状态，此时的TCP处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。

  第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。

  即服务端没有要向客户端发出的数据，服务端发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），服务端进入LAST_ACK（最后确认）状态，等待客户端的确认。

  第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

  即客户端收到服务端的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），客户端进入TIME_WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态。

  收到一个FIN只意味着在这一方向上没有数据流动。客户端执行主动关闭并进入TIME_WAIT是正常的，服务端通常执行被动关闭，不会进入TIME_WAIT状态。

  在socket编程中，任何一方执行close()操作即可产生挥手操作。

• 

• 6.1 挥手为什么需要四次？

  因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四次挥手。

 

7、Cookie和Session的区别：

• 区别：
  • http的请求时无状态的，cookie标识这一种身份；cookie是服务端生成的
  • cookie在request头部，客户端（浏览器）头信息中
  • session：在服务端存储，文件、数据库等都可以存，Redis缓存session（过期机制）
  • session的验证需要cookie带一个字段来表示这个用户是哪一个session

  • 1、Cookie和Session都是会话技术，Cookie是运行在客户端，Session是运行在服务器端。

  • 2、Cookie有大小限制以及浏览器在存cookie的个数也有限制，Session是没有大小限制和服务器的内存大小有关。

  • 3、Cookie有安全隐患，通过拦截或本地文件找得到你的cookie后可以进行攻击。

  • 4、Session是保存在服务器端上会存在一段时间才会消失，如果session过多会增加服务器的压力

• cookie：
  • Cookie技术是客户端的解决方案，Cookie就是由服务器发给客户端的特殊信息，而这些信息以文本文件的方式存放在客户端， 然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息。
  • 客户端发送一个http请求到服务器端
  • 服务器端发送一个http响应到客户端，其中包含Set-Cookie头部
  • 客户端发送一个http请求到服务器端，其中包含Cookie头部
  • 服务器端发送一个http响应到客户端
• session：
  • Session保存在服务器上。 客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。 客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。
  • 服务器一般把Session放在内存中。 每个用户都会有一个独立的Session。Session在用户第一次访问服务器的时候自动创建, 创建Session的同时，服务器会为该Session生成唯一的session id,session id会以cookie的方式发送个客户端。
  • 客户端下次访问时，带上这个session id，就可以跟踪会话了。如果浏览器不支持cookie，可以用url重写的方式，将sessionId写入url传给服务器。