TCP是可靠的传输控制协议，而三次握手是保证数据可靠传输又能提高传输效率的最小次数。为什么？TCP的协议RFC中谈到了原因：
为了实现可靠数据的传输，TCP协议的通信双方，都必须维护一个序列号，以标识发送出去的数据包中，哪些是已经被对方收到的。
比如：发送方再发送数据包（假设大小为10byte）时，同时送上一个序号（假设为500），那么接收方收到这个数据包后，就可以回复一个确认号（510 = 500+10）告诉发送方“我已经收到了你的数据包，你可以发送下一个数据包，序列号从511开始“。
三次握手的过程即是通信双方相互告知序列号起始值，并确认对方已经收到了序列号起始值的必经步骤。
如果只是两次握手，至多只有连接发起方的起始序列号能被确认，另一方选择的序列号则得不到确认。
如果是四次握手，很明显，三次握手后，通信的双方都已经知道了对方序列号起始值，也确认了对方知道自己序列号起始值，第四次握手已经毫无必要了。
TIME_WAIT状态存在有两个原因：
1.可靠终止TCP连接。如果最后一个ACK报文因为网络原因被丢弃，此时server因为没有收到ACK而超时重传FIN报文，处于TIME_WAIT状态的client可以继续对FIN报文做回复，向server发送ACK报文；
2.保证让迟来的TCP报文段有足够的时间被识别和丢弃。连接结束了，网络中的延迟报文也应该被丢弃掉，以免影响立即建立的新连接。
TCP是全双工的连接，必须两端同时关闭连接，连接才算真正关闭。
如果一方已经准备关闭写，但是它还可以读另一方发送的数据，发送给FIN结束报文给对方接收后，回复ACK报文。当这方也已经写完了准备关闭，发送FIN报文，对方回复ACK。两端都关闭，TCP连接正常关闭。
DDOS攻击利用合理的服务请求占用过多的服务资源，使正常用户的请求无法得到响应。
常见的DDOS攻击有计算机网络带宽攻击和连通性攻击。
带宽攻击指以极大的通信量冲击网络，使得所有可用网络资源都被消耗殆尽，最后导致合法的用户请求无法通过。
连通性攻击指用大量的连接请求冲击计算机，使得所有可用的操作系统资源都被消耗殆尽，最终计算机无法再处理合法用户的请求。
SYN洪水攻击属于DDOS攻击的一种，它利用TCP协议缺陷，通过发送大量的半连接请求，耗费CPU和内存资源。
客户端在短时间内伪造大量不存在的IP地址，向服务端不断地发送SYN报文，服务端回复ACK确认报文，并等待客户的确认，由于源地址是不存在的，服务器需要不断的重发直至超时，这些伪造的SYN报文被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。
多播的信息一定要用udp实现，因为tcp只支持一对一通信。
如果一个应用场景中大多是简短的信息，适合用udp实现，因为udp是基于报文段的，它直接对上层应用的数据封装成报文段，然后丢在网络中，如果信息量太大，会在链路层中被分片，影响传输效率。
如果一个应用场景重性能甚至重完整性和安全性，那么适合于udp，比如多媒体应用，缺一两帧不影响用户体验，但是需要流媒体到达的速度快，因此比较合适用udp。
如果要求快速响应，那么udp听起来比较合适。
如果又要利用udp快速响应优点，又想要可靠传输，那么只能靠上层应用自己定制规则了，比如UDT。
常用的使用udp的例子：多播、聊天等；
登陆采用TCP协议和HTTP协议，你和好友之前发送消息，主要采用UDP协议，内网传文件采用P2P技术。总的来说：
1.登陆过程，客户端client采用TCP协议向服务器server发送消息，HTTP协议下载信息。登陆之后，会有一个TCP连接来保持在线状态。
2.和好友发消息，客户端client采用UDP协议，但是需要通过服务器转发。腾讯围栏确保传输消息的可靠，采用上层协议来保证可靠传输。如果消息发送失败，客户端会提示消息发送失败，并支持重新发送。
3.如果是在内网里面的两个客户端传文件，QQ采用的是P2P技术，不需要服务端中转。
BIO：一个连接一个线程，客户端有连接请求时服务端就需要启动一个线程进行处理。线程开销大。
伪异步IO：将请求连接放入线程池，一对多，但线程还是很宝贵的资源。
NIO：一个请求一个线程，但客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有I/O请求时才启动一个线程进行处理。
AIO：一个有效请求一个线程，客户端的I/O请求都是由OS先完成了再通知服务器应用去启动线程进行处理；
BIO是面向流的，NIO是面向缓冲区的；BIO的各种流是阻塞的。而NIO是非阻塞的；BIO的stream是单向的，而NIO的channel是双向的。
NIO的特点：事件驱动模型、单线程处理多任务、非阻塞I/O，I/O读写不再阻塞，而是返回0、基于block的传输比基于流的传输更高效、更高级的IO函数zero-copy、IO多路复用大大提供了Java网络应用的可伸缩性和实用性、基于Reactor线程模型。
在Reactor模式中，事件分发器等待某个事件或者可应用某个操作的状态发送，事件分发器就把这个事件传给事先注册的事件处理函数或者回调函数，由后者来做实际的读写操作。如在Reactor中实现读；注册读就绪事件和相应的事件处理器、事件分发器等待事件、事件到来，激活分发器，分发器调用事件对应的处理器、事件分发器完成实际的读操作，处理读取到的数据，注册新的事件，然后返还控制权。
Buffer：与Channel进行交互，数据是从Channel读入缓冲区，从缓冲区写入Channel中的；
flip方法：反转此缓冲区，将position给limit，然后将position置为0，其实就是切换读写模式；
clear方法：清除此缓冲区，将position置为0，把capacity的值给limit。
rewind方法：重绕此缓冲区，将position置为0；
DirectVByteBuffer可减少一次系统空间到用户空间的拷贝。但Buffer创建和销毁的成本更高，不可控，通常会用内存池来提供性能。直接缓冲区主要分配给那些易受基础系统的本机I/O操作影响的大型、持久的缓冲区。如果数据量比较小的中小应用情况下，可以考虑使用heapBuffer，由JVM进行管理。
Channel:表示IO源与目标打开的连接，是双向的，但不能直接访问数据，只能与Buffer进行交互。通过源码可知，FileChannel的read方法和write方法都导致数据复制了两次。
Selector可使一个单独的线程管理多个Channel，open方法可创建Selector，register方法向多路复用器注册通道，可以监听的事件类型：读、写、连接、accept。注册事件后会产生一个SelectionKey；它表示SelectableChannel和Selector之间的注册关系。wakeup方法；使尚未返回的第一个选择操作立即返回，唤醒的原因是：注册了新的channel或者事件：channel关闭，取消注册；优先级更高的事件触发【如定时器事件】，希望及时处理。
NIO的服务端建立过程：Selector.open():打开一个Selector;
ServerSocketChannel.open（）：创建服务端的Channel;
bind()：绑定到某个端口上；
配置非阻塞模式；
register();
注册Channel和关注的事件到Selector上；
select()轮询拿到已经就绪的事件；
1.缓存处理，在1.0中主要使用header里的if-Modified-Since，Expires来作为缓存判断的标准，1.1则引入了更多的缓存控制策略，例如Entity tag，if-Modified-Since，if-Match，if-None-Match等更多可供选择的缓存头来控制缓存策略。
2.带宽优化及网络连接的使用;
3.错误通知的管理；
4.Host头处理；
5.长连接，1.1支持长连接和请求的流水线处理，在一个TCP连接上可以传送多个Http请求和响应，减少了建立和关闭连接的消耗和延迟，1.1中默认开启connection：keep-alive，一定程度上弥补了1.0每次请求都要创建连接的缺点；
1.新的二进制格式，1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，之人0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
2.多路复用，即连接共享，即每一个request都是用作连接共享机制的，一个request对应一个id，这样一个连接上可以有多个request，每一个连接的request可以随机的混杂在一起，接收方可以根据request的id将request再归属到各自不同的服务端请求里面。
3.header压缩，前面提到的1.x的header带有大量信息，而且每次都要重复发送，2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减少了需要传输的大小。
4.服务端推送，2.0也具有服务端推送消息功能；
1.x：一次请求-响应，建立一个连接，用完关闭；每一个请求都要建立一个连接；
1.1 Pipeling解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获取执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞；
2.0多个请求可同时在一个连接上并行执行、某个请求任务耗时严重，不会影响到其他连接的正常执行；
HTTPS协议：一般理解为HTTP+SSL/TLS。通过SSL证书来验证服务器的身份，并为浏览器和服务器之间的通信进行加密；
1.HTTP的URL是以开头，而HTTPS是以开头；
2.HTTP是不安全的，而HTTPS是安全的；
3.HTTP标准端口是80，而HTTPS的标准端口是443
4.在OSI网络模型中，HTTP工作于应用层，而HTTPS的安全传输机制工作在传输层；
5.HTTP无法加密，而HTTPS对传输的数据进行加密；
6.HTTP无需证书，而HTTPS需要CA机构颁发的SSL证书；
1.客户使用https的URL访问web服务器，要求与web服务器建立SSL连接；
2.web服务器收到客户端请求后，会将网站的证书信息（证书中包含服务器公钥<非对称加密>）传送一份给客户端（HTTPS中，服务端将公钥发给数字证书认证机构进行安全认证并对公钥进行数字签名，完成后公钥和签名组合成数字证书。在和客户端通信时，服务端将数字证书发给客户端，客户端通过第三方安全认证机构【一般会在浏览器开发时，内置在浏览器中】对数字证书上的签名进行验证）。
3.客户端的浏览器与web服务器开始协商SSL连接的安全等级，也就是信息加密的等级。
4.客户端的浏览器根据双方同意的安全等级，建立会话密钥<对称加密>，然后利用服务器公钥将会话密钥加密，并传送给网站；
5.web服务器利用自己的私钥解密出会话密钥；
6.web服务器利用会话密钥加密与客户端之间的通信；
1.首先进行DNS域名解析（本地浏览器缓存、操作系统缓存或者DNS服务器），首先会搜索浏览器自身的DNS缓存（缓存时间比较短，大概只有1分钟，且只能容纳1000条缓存）；
a.如果浏览器自身的缓存里面没有找到，那么浏览器会搜索系统自身的DNS缓存；
b.如果还没找到，那么尝试从hosts文件里面去找；
c.在前面三个过程中都没有获取到的情况下，就去域名服务器去查找；
2.三次握手建立TCP连接；
3.客户端发起HTTP请求；
4.服务器响应HTTP请求；
5.客户端解析html代码，并请求html代码中的资源；
6.客户端渲染展示内容；
7.关闭TCP连接
200:请求被正常处理；
204:请求被受理但没有资源可以返回；
206:客户端只是请求资源的一部分，服务端只对请求的部分资源执行GET方法，相应报文中通过Content-Range指定范围的资源；
301:永久性重定向；
302:临时性重定向；
303：与302状态码有相似功能，只是希望客户端在请求一个URL的时候，能通过GET方法重定向到另一个URL上；
304：发送附带条件的请求时，条件不满足时返回，与重定向无关；
307:临时重定向，与302类似，只是强制要求使用POST方法；
400:请求报文语法有误，服务器无法识别；
401:请求需要认证；
403:请求的对应资源禁止被访问；
404:服务器无法找到对应资源；
500:服务器内部错误；
503:服务器正忙；
本文发布于:2024-02-01 13:26:20，感谢您对本站的认可！
本文链接：https://www.4u4v.net/it/170676518036921.html
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。
| 留言与评论（共有 0 条评论） |
