计算机网络考点

1.http和https区别

Http：超文本传输协议。以明文方式发送信息，端口80
https:是http的安全版，使用的是SSL协议，传输之前身份认证、交换密钥，端口443
模块请求http改成了https，测试方案该如何制定？
① 使用https登录，登录成功并且地址栏有一把锁，则说明该网站部署了SSL
② 使用http登录，登陆成功则说明该网站没有强制https登录
③ 使用http登录，跳转至https页面，则说明该网站设置了http自动跳转至https

2.错误码

400：无效语法；
401：未授权，需要身份认证，正当的认证凭据；
403：禁止访问，修改agent或更改ip；
404：文件找不到；
408：请求超时
416：服务器无法处理所请求的数据区间
503：服务不能用

3.三次握手

第一次握手：客户端发送syn包(syn=x)到服务器，等待服务器确认；SYN_SEND
第二次握手：服务器收到syn包，确认包，同时自己发送一个syn包，即syn+ack包；SYN_RECV
第三次握手：客户端收到服务器的syn+ack包，向服务器发送确认包ack，进入连接状态ESTABLISHED
握手过程中不传递数据，三次握手后才传输数据
采用二次握手行吗？采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。

4.四次挥手

第一次挥手：主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不 会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可以接受数据。
第二次挥手：被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。
第三次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。
第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。
为什么会采用四次挥手，若采用三次挥手可以吗？
因为关闭连接时，server端收到客户端的FIN报文，并不会立即关闭socket，只能先回复一个ACK告诉client我已经收到你的关闭请求了，同时可能server还有数据没传输完，只有等server端数据传输完成了 才能发送FIN报文，所以这个地方要分两次发送，这样就有了四次挥手。

5.TCP与UDP区别

区别：
1、面向连接VS无连接
TCP建立一个连接需要3次握手IP数据包，断开连接需要4次挥手。另外断开连接时发起方可能进入TIME_WAIT状态长达数分钟（视系统设置，windows一般为120秒），在此状态下连接（端口）无法被释放。
UDP不需要建立连接，可以直接发起。
2、可靠VS不可靠
TCP利用握手、ACK和重传机制，udp没有。

• 校验和（校验数据是否损坏）；
• 定时器（分组丢失则重传）；
• 序列号（用于检测丢失的分组和重复的分组）；
• 确认应答ACK（接收方告知发送方正确接收分组以及期望的下一个分组）；
• 否定确认（接收方通知发送方未被正确接收的分组）；
• 窗口和流水线（用于增加信道的吞吐量）。（窗口大小：无需等待确认应答而可以继续发送数据的最大值）

3、有序性
TCP利用seq序列号对包进行排序，udp没有。
4、面向字节流vs面向报文

• 面向报文
  面向报文的传输方式是应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。因此，应用程序必须选择合适大小的报文。若报文太长，则IP层需要分片。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。这也就是说，应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。（一个upd的最大报文长度2^16-1-20-8,20是ip报文头，8是udp报文头）
• 面向字节流
  面向字节流的话，虽然应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序看成是一连串的无结构的字节流。TCP有一个缓冲，当应用程序传送的数据块太长，TCP就可以把它划分短一些再传送。如果应用程序一次只发送一个字节，TCP也可以等待积累有足够多的字节后再构成报文段发送出去。

5、tcp有流量控制，udp没有
6、tcp的头部比20bytes，udp8bytes
应用场景：

• TCP应用场景：
  效率要求相对低，但对准确性要求相对高的场景。因为传输中需要对数据确认、重发、排序等操作，相比之下效率没有UDP高。举几个例子：文件传输（准确高要求高、但是速度可以相对慢）、接受邮件、远程登录。
• UDP应用场景：
  效率要求相对高，对准确性要求相对低的场景。举几个例子：QQ聊天、在线视频、网络语音电话（即时通讯，速度要求高，但是出现偶尔断续不是太大问题，并且此处完全不可以使用重发机制）、广播通信（广播、多播）。

7.断点续传

断点续传支持从文件上次中断的地方开始传送数据，而并非是从文件开头传送。
断点续传功能最核心的原理就是利用HTTP1.1（RFC2616）中定义header中定义的Range和contentRange字段。
Range ：
用于请求头中，指定第一个字节的位置和最后一个字节的位置，一般格式：Range:(unit=first byte pos)-[last byte pos]
常用的格式有如下几种情况：
Range:bytes=0-1024 ，表示传输的是从开头到第1024字节的内容；
Range:bytes=1025-2048 ，表示传输的是从第1025到2048字节范围的内容；
Range:bytes=-2000 ，表示传输的是最后2000字节的内容；
Content-Range：
用于响应头，指定整个实体中的一部分的插入位置，他也指示了整个实体的长度。在服务器向客户返回一个部分响应，它必须描述响应覆盖的范围和整个实体长度。
常见的格式内容如下：
Content-Range:bytes 2048-4096/10240
这里边 2048-4096 表示当前发送的数据范围， 10240 表示文件总大小。

8.cookies和session区别

cookie和session的关系和区别
cookie保存在浏览器端，session保存在服务器端，但是为了区分不同的客户端，服务器会在浏览器中发送一个对应的sessionid保存到cookies中，下次浏览器请求服务器的时候会将sessionid一并发送给服务器。所以session机制依赖于cookie机制
1、cookie数据存放在客户的浏览器上，session数据放在服务器上。
2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗考虑到安全应当使用session。
3、session会在一定时间内保存在服务器上。当访问增多，会比较占用服务器的性能。考虑到减轻服务器性能方面，应当使用COOKIE。
4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
5、建议：将登陆信息等重要信息存放为SESSION
其他信息如果需要保留，可以放在COOKIE中

9、浏览器访问百度的过程

要先使用 arp 获取默认网关的 mac 地址
1、组织数据发送给默认网关(ip 还是 dns 服务器的 ip，但是 mac 地址是默认网关的 mac 地址)
2、默认网关拥有转发数据的能力，把数据转发给路由器
3、路由器根据自己的路由协议，来选择一个合适的较快的路径转发数据给目的网关
4、目的网关(dns 服务器所在的网关)，把数据转发给 dns 服务
5、dns 服务器查询解析出 baidu.com 对应的 ip 地址，并原路返回请求这个域名的 client，得到了 baidu.com 对应的 ip 地址之后，会发送 tcp 的 3 次握手，进行连接
6、使用 http 协议发送请求数据给 web 服务器
7、web 服务器收到数据请求之后，通过查询自己的服务器得到相应的结果，原路返回给浏览器
8、浏览器接收到数据之后通过浏览器自己的渲染功能来显示这个网页
9、浏览器关闭 tcp 连接，即 4 次挥手结束，完成整个访问过程

10、网页卡顿原因

1、网速慢、带宽不足、硬件配置低、内存被占满。
2、JS脚本过大，阻塞了页面的加载。
3、网页资源过多、接受数据时间长、加载某个资源慢。
4、DNS解析速度慢。
一般怎么检查
1、硬件问题：检查网线或者无限网卡有没有插好，有没有连上路由器，就是底层是不是联通状态；
2、软件问题：查看是否有对应的驱动，服务器好不好，DNS对不对，或者可能是代理没关

TCP怎么实现可靠传输（了解知识）

1、确认和重传机制：建立连接、发送包时的确认，运输过程中校验失败、丢包或延时发送端重传
2、数据排序：把数据分成很多包，按顺序进行传输
3、流量控制：滑动窗口和计时器。

• 流量控制：作用于接收方，控制发送者的发送速度从而使接收者来得及接收，防止分组丢失的。由滑动窗口实现
• 滑动窗口：TCP进行流量控制的方式，接收方通过告诉对方自己的窗口大小，从而控制发送方的发送速度，以防止由于发送方发送速度过快而导致自己被淹没的现象
• 计时器：发送端收到为0的窗口后开启一个计时器，时间到了之后发包询问现在的滑动窗口，防止死锁（接收端发回的不为0的窗口的包丢失，双方相互等待）

4、拥塞控制：慢启动、拥塞避免、快速重传、快速恢复

• 拥塞控制：作用于网络，防止过多的数据注入到网络中，避免出现网络负载过大的情况。
• 慢启动：不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。拥塞窗口一开始设为1 ，每收到一次确认，就让拥塞窗口变为原来的两倍，当窗口值为16时（慢启动门限），改为加法增大，每次+1，直到网络拥塞。拥塞时让新的慢启动门限设为拥塞时的一半，并把拥塞窗口置为1，再让他重复，这时一瞬间会将网络数据量大量降低。
• 拥塞避免：拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。
• 快重传：接收方每收到一个失序的报文段（收完2后就收到了4说明3丢了）就立即发出包2的重复确认，这样可以让发送方尽早知道丢包了。发送端连续收到三个重复确认就立即重传3。
• 快恢复：发送方收到3个连续确认时，把慢开始门限减半，把拥塞窗口的值置为慢开始门限的一半，实行拥塞避免算法，每次确认收到后+1。