计算机网络-校招总结

计算机网络的重要性不言而喻, 也是计算机基础里面关键的一环与面试热点, 以前收集了一些问题和知识点, 如今此分享

针对目标

• 学完书本知识就忘记的我
• 本科网络工程可是对网络所知甚少的我
• 只偏向于工程应用而不热衷理论研究的我
• 不想在校招中裸奔的我

• 偶尔路过的你

  内容

  计算机网络中热点面试问题, 我认为应该知道的一些基础知识; 不会深究太多, 以我认为够用为界

  网络分层

  七层参考模型

  具体展开再也不深刻
• 应用层
• 表示层
• 会话层
• 传输层
• 网络层
• 链路层

• 物理层

TCP ip模型

应用层

注意事项:
在OSI模型中ARP协议属于链路层；而在TCP/IP模型中，ARP协议属于网络层。

Tcp ip中的数据流

应用层
    定义数据格式，并按照对应的格式解读数据
    应用层定义了各类各样的协议来规范数据格式
        HTTP
        FTP
    好比http报文的头部格式
传输层
    引入相关通讯协议
        定义端口
        为了给每一个应用程序标识身份
        找到IP标定的主机上,具体接收数据的端口
    UDP数据包
    TCP数据包
网络层
    IP地址
        确认主机所在的网络位置，并经过IP进行MAC寻址
        对外网数据包进行路由转发
    在网络层被包装的数据包就叫IP数据包
    网络层的主要工做是定义网络地址，区分网段，子网内MAC寻址，对于不一样子网的数据包进行路由
链路层
    MAC地址
        链路层定义了主机的身份，即MAC地址
        定义数据帧，确认主机的物理地址，传输数据；
    在链路层生成以太网数据包
    以太网数据包经过物理介质传输给对方主机

TCP协议

一些基本问题

TCP与UDP的区别
    TCP面向链接
    可靠的流协议
        顺序控制
        流量控制
        拥塞控制
    UDP
        有更高的实时性
        不可靠的数据报协议
        不能保证必定会送达

为何要三次握手?
    三次握手的目的是创建可靠的通讯信道
    双方确认本身与对方的发送与接收是正常的

三次握手的过程

    客户端发送syn包(seq=x)到服务器
        客户端SYN_SEND状态，等待服务器确认
    服务器收到syn包，必须确认客户的SYN(ack=x+1)，同时本身也发送一个SYN包(seq=y)，即SYN+ACK包
        服务器进入SYN_RECV状态
    客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1)，
        此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手

TCP四次握手

        客户端或服务器都可主动发起挥手动做，在socket编程中，任何一方执行close()操做便可产生挥手操做

        1.主动方申请关闭链接,发送FIN报文,意味着这一方没有要发送的数据了!
                状态变为FIN-WAIT-1
        2.被动方接收,发送ACK,先发送一个确认, ACK和ack
            这时候尚未真正的发送完被动方的数据
            状态变为CLOSE_wait
        3.主动方状态变为FIN-wait2
            被动方发送FIN, 意味着被动方也发送完了
            LAST-ack状态
        4.主动方发送确认,正式要关闭链接
            主动方等待2MSL后,没有回复 关闭链接

TCP协议中的一些细节

tcp如何保证可靠性

使用以下技术

• 校验和
• 序列号
• 确认应答
• 重发控制
• 链接管理
• 窗口管理

TCP怎么保证链接的惟一性

• TCP/IP惟一性含除地址和端口外, 还有一个时间上的标记才可彻底确立。
• 对TCP而言在三次握手时的SYN标志会使用上一个ISN值
• 每一次链接都会分配到一个ISN值，链接双方对这个值会记录共识，假如这个值不一，就说明了这个链接已超时或无效

TCP窗口的做用

• 进行流量控制的
• tcp的应答不是对每一个段的
• 而是以一个更大的单位-窗口

tcp 粘包拆包问题是怎么产生的？何时会发生? 怎么来解决?

• tcp的协议数据不会丢，没有收完包，下次接收，会继续上次继续接收，己端老是在收到ack时才会清除缓冲区内容。数据是可靠的，可是会粘包和拆包问题。(UDP不会发生粘包)
• 两种状况下发生粘包: 发送端须要等缓冲区满才发送出去，两个数据包过小了,形成粘包; 客户端发送了一段数据，服务端只收了一小部分，服务端下次再收的时候仍是从缓冲区拿上次遗留的数据，产生粘包.
• 两种状况下发生拆包:要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包; 待发送数据大于MSS（最大报文长度），TCP在传输前将进行拆包
• 解决的关键: 接收端不知道发送端将要传送的字节流的长度，因此解决粘包的方法就是围绕: 如何让接收端有办法知道哪里是终止.
• 方法1:发送端给每一个数据包添加包首部，首部中应该至少包含数据包的长度，这样接收端在接收到数据后，经过读取包首部的长度字段，便知道每个数据包的实际长度了。
• 方法2:发送端将每一个数据包封装为固定长度（不够的能够经过补0填充）
• 方法3:能够在数据包之间设置边界，如添加特殊符号，这样，接收端经过这个边界就能够将不一样的数据包拆分开

TCP的拥塞控制

思路
    为防止传输的阻塞,经过一个慢启动获得的数值来控制发送的数据量
    发送方维持一个叫作拥塞窗口的状态变量
    不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增长拥塞窗口的大小
    主要要记住的就是下面四个算法,
慢启动阶段
    意思是刚刚加入网络的链接，一点一点地提速，不要一上来就把路占满。
    把拥塞窗口设为1个数据段
    指数性增长,直到第一次丢失
拥塞避免
    到达一个阈值后,开始线性增长
快重传
    快重传要求接收方在收到一个失序的报文段后就当即发出重复确认
快恢复
    和快重传算法配合使用，当发送方连续收到3个重复确认时就执行乘法减少算法，把慢开始门限ssthresh减半
    但因为发送 方 连续 收到 几个重传确认，因此认为此事网络无阻塞，因此此时不执行慢开始算法，而是让cwnd 从 ssthresh开始执行拥塞避免算法（加法增大）。

HTTP协议

什么是http协议?
    是一个基于请求与响应模式的
    无状态的
    基于TCP的链接方式
    应用层的协议

http请求方法
    经常使用的方法有哪些?
        get
        post
    get 和 post 请求有哪些区别？
        get的参数在url中
        post的经过request Body传递
        GET请求在URL中传送的参数是有长度限制的
        get重点在从服务器上获取资源

post重点在向服务器发送数据
        get是不安全的，由于URL是可见的，可能会泄露私密信息，如密码等；

post较get安全性较高；

http请求报文和响应报文
    请求报文
        请求行
        请求首部字段
        请求实体
    响应
        状态行
        响应首部字段
        响应实体

http协议2.0和1.1的区别
    HTTP/2是彻底多路复用的
    HTTP/2采用二进制格式而非文本格式
    HTTP/2让服务器能够将响应主动“推送”到客户端缓存中
    header压缩

https的原理，如何加密解密
    Https在真正请求数据前，先会与服务有几回握手验证，以证实相互的身份
    客户端向服务器发起HTTPS请求，链接到服务器的443端口
    服务器将本身的公钥发送给客户端
    客户端收到服务器端的公钥以后，会对公钥进行检查，验证其合法性
        验证成功,生成随机的对称秘钥
    客户端会发起HTTPS中的第二个HTTP请求，将加密以后的客户端密钥发送给服务器
    服务器接收到客户端发来的密文以后，会用本身的私钥对其进行非对称解密
        这样两边就有了一对对称秘钥
    以后就能够了

http经常使用状态码
    1xx：指示信息--表示请求已接收，继续处理
    2xx：成功--表示请求已被成功接收、理解、接受
        200：请求被正常处理
        204：请求被受理但没有资源能够返回
    3xx：重定向--要完成请求必须进行更进一步的操做
        301：永久性重定向
        302：临时重定向
    4xx：客户端错误--请求有语法错误或请求没法实现
        400：请求报文语法有误，服务器没法识别
        401：请求须要认证
        403：请求的对应资源禁止被访问
        404：服务器没法找到对应资源
    5xx：服务器端错误--服务器未能实现合法的请求
        500：服务器内部错误
        503：服务器正忙