最近回来的这两个星期,一直在准备笔试和面试。目前也写了5W 多字的知识点复习。网上对各种题型、各种知识点的说法很多,自己写总结也是为了更好的复习吧。上周六网易笔试,笔试完就很丧。就编程题测试案例能通过,实际运行就是很低的通过率。这当中还有很多内存占用、位数不够、输出规范等还要注意的问题。只能通过不断的笔试练习来完善。刷笔试还是要不断做编程题,虽然逻辑上没有非常难理解。最关键的还是要注意代码的规范,尽量不必要的使用空间等。
这里就先写一些总结的知识点:
一、Http,HTML,浏览器
http:超文本传输协议,是互联网上应用最广泛的一种网络协议,是客户端和服务端请求和应答的标准(TCP),用于从服务器传输超文本到本地浏览器的传输协议,可以使浏览器更加高效,网络传输减少。
https:简单来讲就是在 http 下加入 SSL加密,是以安全为目标的http通道。主要作用就是建立一个信息安全通道,用来保证数组的传输,确保网站的真实性。https 采用的是混合加密机制
http 传输的数据都是未加密的,也就是明文的。而https 通过使用 SSL 对传输的数据进行加密和身份认证,比 http 协议的安全性更高。http 是无状态的明文传输,端口是 80;而https 需要ca 证书,费用高,端口是443,是有身份的网络协议,比http 更安全
1、客户端发起 https 请求。也就是用户在浏览器里输入一个 Https 网址,然后连接到server 的443 端口
2、服务端配置。被连接的服务器有一套数字证书,可以自己制作也可以申请。证书里包含一对公钥和私钥。公钥就相当于一个锁头,私钥就是钥匙。
3、传送证书。服务器给客户端发送公钥。
4、客户端解析证书。这里是由TLS 来完成的。首先验证公钥是否有效,如果发现异常会弹出一个提示框,告诉用户存在的问题。如果证书没问题,就生成一个随机值(这个随机盒子就相当于客户端自己的私钥),然后用证书对该随机值进行加密。也就相当于把随机值用锁头锁起来,此时除非有钥匙,不然打不开。
5、传送加密信息。把随机值经过公钥加密后的随机发送给服务器,以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
6、服务端解密信息。服务端用私钥解密后,得到了客户端传送的随机值,然后把要发送的内容通过随机值进行对称加密。对称加密就是,将信息和私钥通过某种算法混合在一起,这样除非知道私钥,不然不能获取内容。
7、传输加密后的信息。
8、客户端解密信息。客户端用之前生成的随机值(私钥)解密服务端传过来的信息,就是解密之后的内容,整个过程即使监听到了数据,也不能拿到完整的信息。
对称加密虽然简单性能也好,但是首次把密钥发送给对方时,很容易被拦截。
这里介绍非对称加密:
非对称加密:
非对称加密虽然安全性更高,但是响应速度慢,影响性能
解决方案:结合两种加密方式,将对称加密的密钥,使用非对称加密的公钥进行加密,然后接收方只能用私钥解,最后双方可以使用对称加密来进行沟通。
但是还有缺陷,如果存在一个中间人把通信的公钥换成他自己的公钥,这样就可完全拿到通信的数据。这样需要一个安全的第三方证明身份,放置被中间人攻击。但是如果中间人篡改了证书,证书也就没用了。
终极武器:数字签名。先用Hash 算法对证书的内容进行Hash 得到一个摘要,再用CA的私钥加密,生成最终的数字签名。当别人把证书发过来的时候,用相同的hash 算法生成消息摘要,用CA的公钥对数字前面解密的得到消息摘要。两个消息摘要一对比,就知道是否被中间人篡改了。
1、文件校验
2、数字签名: Hash 值,又称"数字摘要"进行数字签名
3、鉴权协议:在传输信道是可被侦听,但不可被篡改的情况下,这是一种简单而安全的方法
客户端向服务器发送请求,服务端确认能收到客户端的信息(第一次);服务端确认收到并返回给客户端带有公钥的网站证书(第二次),客户端与服务端协商SSL链接的安全等级,同时使用公钥来加密会话密钥并发送给服务端(第三次),服务端通过私钥解密会话密钥实现与客户端之间的通信。
1、客户端A发送一个FIN,用来关闭客户A到服务器B的数据传送。
2、服务器B收到这个FIN,它发回一个ACK,确认序号为收到的序号加1。和SYN一样,一个FIN将占用一个序号。
3、服务器B关闭与客户端A的连接,发送一个FIN给客户端A。
4、客户端A发回ACK报文确认,并将确认序号设置为收到序号加1。
三次握手是为了:防止已失效的请求报文又突然传递给服务器。
当A客户端发出连接请求,这时因为网络节点长时间滞留了,而A未等到确认,于是A又发送了一个请求,此时建立了连接,等到第二个连接释放后才到达B。此时B会认为是一个新的连接请求,于是向A发送连接确认。但是此时A已经完成了数据请求,对B给的连接确认一脸懵逼,直接丢掉。当然此时B也不会一直在等A的请求,它有一个保活计时器,如果超过计时器的时间A还没发送请求过来,那就不会再等了。
四次挥手的TIME_WAIT 状态:
第一是为了保证最后一个 ACK 报文能到达B。这个ACK 报文有可能丢失,使得处于Last_Ack 状态得不到对已发送的Fin+Ack 报文的确认,B会超时重传这个Fin+Ack。而A 就能在Time_Wait 时间里收到这个重传的报文。A就可以重传一次确认。如果没有这个Time_Wait ,B重传的Fin_Ack ,可A 早就走了,不会再重发确认;B无法按照正常步骤进入 close 状态。
第二是防止“已失效的报文连接请求”,A在TIME_WAIT中,经过这2MSL的时间,就可以使本链接持续的时间内产生的所有连接消失,这样就可以使下一个新的连接中不会出现这样旧的连接请求报文段。
聪明的你会发现谁先关闭谁就有一个TIME_WAIT的状态;
在linux的网络编程中,如果服务器如果先关闭,你会发现,现在想要立马再次启动服务器,就会报错说这个端口号被占用着,那就是因为有这个TIME_WAIT,2msl的时间.那么怎么解决 ?
解决:setsockopt()函数。在这就不多说了。
拥塞:对资源的需求超过了可用的资源。
拥塞控制:防止过多的数据注入到网络中,使网络中的路由器或链路不至于过载。前提是:网络能够承受现有的网络负荷。
拥塞控制的方法:
慢开始、拥塞避免、快重传、快恢复
3. 快重传和快恢复。快重传:接收方收到一个失序的报文段后,立即发出重复的确认。也就是当某个数据A丢失后,之后收到的回复都表明A已丢失。发送方收到3次A已丢失的回复后,立即重新发送A。快恢复:当发送方收到三个重复确认时,把发送的阈值减小一半,然后执行拥塞避免算法(此时不执行慢开始),让拥塞窗口逐渐增大
流量控制解决的问题是如果发送方把数据发送得过快,接收方可能会来不及接收,这就会造成数据的丢失。
优点:可以认证用户与服务器,确保数据发送到正确的客户机与服务器,它比 http 协议更安全,防止数据传输过程中不被窃取、改变,保证数据的完整性。
缺点:握手阶段比较费时,增加耗电;会增加数据的开销;SSL 证书随着功能的强大费用越高;SSL 证书要绑定IP ,不能在同一个ip 上绑定多个域名
TCP 是面向连接的,而udp 在发送数据前不需要先建立连接
TCP 提供的服务更可靠,可以保证数据的无差错,不丢失,不重复,因此适合传输大数据量的交换;而 udp 不能保证可靠交付
TCP 面向的是字节流,在出现网络拥塞时不会降低发送速率,而 udp 面向报文,在有拥塞时会导致丢包
TCP 只能1对1传输数据,而 udp 支持1对多
TCP 的首部可以有20字节,而 udp 只有8字节
TCP 是可靠传输,而 udp 是不可靠的
TCP的优点: 可靠,稳定 TCP的可靠体现在TCP在传递数据之前,会有三次握手来建立连接,而且在数据传递时,有确认、窗口、重传、拥塞控制机制,在数据传完后,还会断开连接用来节约系统资源。 TCP的缺点: 慢,效率低,占用系统资源高,易被攻击 TCP在传递数据之前,要先建连接,这会消耗时间,而且在数据传递时,确认机制、重传机制、拥塞控制机制等都会消耗大量的时间,而且要在每台设备上维护所有的传输连接,事实上,每个连接都会占用系统的CPU、内存等硬件资源。 而且,因为TCP有确认机制、三次握手机制,这些也导致TCP容易被人利用,实现DOS、DDOS、CC等攻击。
UDP的优点: 快,比TCP稍安全 UDP没有TCP的握手、确认、窗口、重传、拥塞控制等机制,UDP是一个无状态的传输协议,所以它在传递数据时非常快。没有TCP的这些机制,UDP较TCP被攻击者利用的漏洞就要少一些。但UDP也是无法避免攻击的,比如:UDP Flood攻击…… UDP的缺点: 不可靠,不稳定 因为UDP没有TCP那些可靠的机制,在数据传递时,如果网络质量不好,就会很容易丢包。 基于上面的优缺点,那么: 什么时候应该使用TCP: 当对网络通讯质量有要求的时候,比如:整个数据要准确无误的传递给对方,这往往用于一些要求可靠的应用,比如HTTP、HTTPS、FTP等传输文件的协议,POP、SMTP等邮件传输的协议。 在日常生活中,常见使用TCP协议的应用如下: 浏览器,用的HTTP FlashFXP,用的FTP Outlook,用的POP、SMTP Putty,用的Telnet、SSH QQ文件传输 ………… 什么时候应该使用UDP: 当对网络通讯质量要求不高的时候,要求网络通讯速度能尽量的快,这时就可以使用UDP。 比如,日常生活中,常见使用UDP协议的应用如下: QQ语音 QQ视频 TFTP 等
TCP与UDP区别总结:
1、TCP面向连接(如打电话要先拨号建立连接);UDP是无连接的,即发送数据之前不需要建立连接
2、TCP提供可靠的服务。
通常用的都是短连接:得到一个请求,一个县城处理完该请求,请求就关闭。但当客户端发送的请求很多,服务器就会忙于建立连接,处理请求。如果并发量大的话,服务器会崩溃。现在要一个方法:一个线程可以处理多个连接-----> 使用长连接
优点:减少了连接请求,降低了 TCP 阻塞,减少了延迟,实时性较好
这里主要分两种长连接实现:[http 会一直占用线程,而 servlet3 不会一直占用]
与后面 webSocket 的区别:
WebSocket: 客户端发送一次http websocket请求,服务器响应请求,双方建立持久连接,并进行双向数据传输,后面不进行HTTP连接,而是使用TCP连接。
长连接:在HTTP 1.1,客户端发出请求,服务端接收请求,双方建立连接,在服务端没有返回之前保持连接,当客户端再发送请求时,它会使用同一个连接。这一直继续到客户端或服务器端认为会话已经结束,其中一方中断连接。用的是 http 连接。
http 和 tcp 都有 keepalive。
tcp 的keep-alive 侧重保持客户端和服务端的连接,一方会不定期发送心跳包给另一方,没断的发送几次心跳包。如果间隔发送几次,对方返回的都是 RST ,而不是ACK ,那么就释放当前链接。这样可以及时释放服务器的资源。tcp 层的 keepalive 主要包括三个参数:最后一次的连接时间、多少间隔发送一次心跳包,发送probs 次心跳包未收到响应则关闭连接.
http 的keep-alive 一般中间都会带上横杠。客户端告诉服务端,这个连接之后还会继续使用,避免进行重复的三次握手和四次挥手环节。(http 没啥原理好讲的,主要就是 Connection: keep-alive 字段,关闭的时候用 Connection : close 关闭)
目前为止市场上广泛使用的http 版本依然是1.1 ,从1997年发布至今还在使用
优点:
缺点
HTTP1.0定义了三种请求方法: Get, Post 和 Head方法
HTTP1.1新增了五种请求方法:Options, Put, Delete, Trace 和 Connect
Get:请求服务器的发送某些资源
Post:发送数据给服务器
Head:请求资源的头部信息,并且与Get 方法请求时返回的一致。使用场景示例:下载一个大文件前,先获取其大小再决定是否要下载,因此可以节约带宽
Options:用于获取目的资源支持的通信选项
Put:给服务器新增资源或使用有效负载替换目标资源
Delete:删除指定的资源
Trace:回显服务器收到的请求,主要用于测试或诊断
Connect:HTTP1.1 中预留给将连接改为管道方式的代理服务器
使用场景举例。
如果要写一篇文章的时候,用的就是Post ,如果多次提交这个请求会创建多个文章,这个就是非幂等
如果要更新某篇文章下面的文章,那这个url 指向的就是单一资源,而且是幂等的。比如要把文章中的 [刘德华] 改成 [李现],提交多少次都是改成 [李现]
put 和 patch 都是更新资源,而 patch 用来对已知资源进行局部更新
1、patch 更新资源时,要写完全部的数据,带有部分更新的数据
而put 是直接覆盖资源
请求报文有4部分组成:请求行、请求头、空行、请求体
请求行示例:GET /index.html HTTP/1.1。
请求头:头部关键字/值对,每行一对,关键字和值用英文冒号”:”分隔
示例:
1、User-Agent:产生请求的浏览器类型。
2、Accept:客户端可识别的内容类型列表。
3、Host:请求的主机名,允许多个域名同处一个IP地址,即虚拟主机。
请求体:
post put 等请求携带的数据
响应报文有4部分:响应行、响应头、空行、响应体响应行:协议版本,状态码+状态码的原因短语。如:HTTP/1.1 200 OK
响应头:响应首部组成
响应体:服务器响应的数据
(报文的格式:响应/请求行、响应/请求头、空行、响应/请求体)