计算机网络相关笔记

OSI开放式互联网参考模型

        物理层；//网卡；机械、电子          比特流
        数据链路层；//交换机                帧
        网络层；//路由器，IP协议            分组
        传输层；//应用间传输
        会话层；//管理通讯，自动收发包寻址；
        表示层；//解决不同系统的兼容问题
        应用层
        
    TCP三次握手：
        
        TCP报文头:
            SourcePort(2个字节)：源端口，传输层
            DestinationPort(2个字节):目的端口，传输层
            SequenceNumber(4个字节):
            AcknowledgeNumber(4个字节):
            ...
            
        TCP Flags
            URG：紧急指针标志
            ACK：确认序号标志
            PSH：push标志
            RST：重置连接标志
            SYN：同步序号，用于建立连接过程
            FIN：finish标志，用于释放连接
        
        全双工通信：双方通信
        
        TCP三次握手中的状态：
            客户端：发送SYN报文 SYN=1，seq=x 并进入SYN_SENT状态
            服务端：监听到报文信息，消耗掉一次序号；第一次握手
                    如果确认连接，则返回
                    SYN=1,ACK=1,seq=y,ack=x+1
                    进入SYN-RCVD
            客户端：接收到报文返回
                    ACK=1,seq=x+1(服务端返回的ack),ack=y+1(服务端返回的序号+1)
                    进入ESTABLISHED状态
            服务端：收到报文后，进入ESTABLISHED状态；
            
            第一次握手：建立连接时，客户端发送SYN包到服务器，并进入SYN-SEND状态
                        等待服务器确认
            
            第二次握手：服务器收到SYN包，必须确认客户的SYN，
                        同时自己也发送一个SYN包，即SYN+ACK包，
                        此时服务器进入SYN_RECV状态
        
            第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1)，
                        此包发送完毕，客户端和服务端进入ESTABLISHED状态，完成三次握手；
                        
        为什么需要三次握手？
            主要是为了初始化SequenceNumber的初始值；互换seq和ack
            
        首次握手的隐患--SYN超时
            Server收到Client的SYN，回复SYN-ACK的时候未收到ACK确认
            Server不断重试直至超时，Linux默认等待63秒才断开连接
            攻击者会采用这种方式将服务端的SYN连接队列耗尽，使得服务器无法正常处理请求；
        针对SYN Flood的防护措施
            使用SourcePort、Destination和时间戳来打造一个tcp_syncookies参数，简称SYN Cookie;
            如果是攻击者，则不会有任何反应
            如果是正常连接，Client会回发SYN Cookie，直接建立连接
            
        建立连接后，Client出现故障怎么办？
            保活机制(keepalive)：
                向对象发送保活探测报文，如果未收到响应则继续发送
                达到保活机制设定的保活上限后，仍未收到响应，则中断连接；
            
            
    TCP的四次挥手：
        第一次挥手：Client发送一个FIN包，用来关闭Client到Server的数据传送，Client进入FIN-WAIT-1状态;
        
        第二次挥手：Server 收到FIN后，发送一个ACK给Client，确认序号为收到序号+1(与SYN相同，一个FIN占用一个序号),server进入CLOSE_WAIT状态；
        
        第三次回收：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态；
        
        第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSE状态，完成四次挥手；
        
        完成后，客户端进入TIME_WAIT状态；最后关闭；
        
        为什么会有TIME_WAIT状态？
            确认有足够的时间让对方收到ACK包；
            避免新旧连接混淆；
        
        为什么需要四次挥手才能断开连接
            因为全双工，发送方和接收方都需要接收到FIN和ACK状态；
            
        服务器出现大量CLOSE_WAIT状态的原因
            对方关闭Socket连接，我方或忙于读或写，没有及时关闭连接；
            解决办法：
                检查代码，可能是没有释放连接；
                检查配置，特别是处理请求的线程配置，可能是没有及时处理关闭的请求；
            当CLOSE_WAIT状态数上千，则需要排查问题了    
        
    UDP简介
        UDP的特点：
            非连接；
            不维护连接状态，支持同时向多个客户端传输相同的消息；
            数据包只有8个字节，额外开销小；
            吞吐量只受限于数据生成速率、传输速率以及机器性能；
            尽最大努力交付，不保证可靠交付，不需要维持复杂的链接状态表；
            面向报文，不对应用程序提交的报文信息进行拆分或者合并；

    TCP滑动窗口
        RTT和RTO
        RTT：发送一个数据包到收到对应的ack，所花费的时间；
        RTO：重传时间间隔；
        
        TCP使用滑动窗口做流量控制与乱序重排
            保证可靠性和流控特性；
        
        TCP的发送方的数据状态：
            1.已经发送且得到确认的
            2.已经发送但未得到确认的
            3.接收端允许发送但未发送的
            4.没有发送且接收端不允许发送的
            
            上述的2,3所组成的部分就是TCP的窗口。本质就是接受方约束发送方传送数据的大小；将发送方的发送数据约束在自己的处理范围内，以加强可靠性；
            
            当窗口中有数据达到状态1，则会将窗口向后滑动到，以此执行下去；滑动位置由接收方的实际处理的返回数据提供；
        
        TCP接收方的数据状态：
            1.已接收且已回复
            2.未回复但已接收
            3.未接受且未回复
            
            该窗口只有在确认对方收到己方发送的位置，即得到ACK确认，才会滑动窗口
            
    HTTP简介
        超文本传输协议HTTP主要特点
            支持客户/服务器模式
            简单快速（只传输请求方法（get,post等）和路径）
            灵活（可以传输任意类型的数据）
            无连接（一次连接后就会断开，但会处于长连接keepalive）
            无状态（不记忆处理状态）
            
        HTTP请求头和请求正文
        HTTP响应头和响应正文
        
        请求/响应的步骤
            客户端连接到WEB服务器
            发送HTTP请求
            服务器接受请求并返回HTTP响应
            释放TCP连接
            客户端浏览器解析HTML内容
        
        在浏览器地址栏输入URL，按下回车之后的流程：
            1.DNS解析(DNS缓存：浏览器缓存，系统缓存，路由器缓存，ips服务器缓存，顶级域名服务器缓存)
            2.TCP连接（三次握手）
            3.发出HTTP请求
            4.服务器处理请求返回HTTP报文
            5.浏览器解析渲染页面
            6.连接结束（四次挥手）
        
        HTTP状态码：
            1xx：指示信息--表示请求已接收，继续处理
            2xx: 成功--表示请求一辈成功接收、理解、接收
            3xx: 重定向--要完成请求必须进行更进一步的操作
            4xx：客户端错误--请求有语法错误或请求无法实现
            5xx：服务器端错误--服务器未能实现合法的请求
            
        常见状态码：
            200 OK ： 正常返回信息
            400 BadRequest：客户端请求有语法错误，不能被服务器所理解
            401 Unauthorized：请求未经授权，这个状态码必须和WWW-Authenticate报头域一起使用
            403 Forbidden 服务器收到请求，但是拒绝提供服务；比如，IP被禁用了
            404 Not Found：请求资源不存在，eg。输入了错误的URL
            500 Internal Server Error: 服务器发生了不可预期的错误
            503 Server Unavailable：服务器当前不能处理客户端请求，一段时间后可能恢复正常；
            
        GET和POST的区别
            1.Http报文层面：GET将请求报文放在URL，POST放在请求体中；
            2.数据库层面：GET符合幂等性和安全性，POST不符合；改变数据，且每次获得结果不一样；
            3.其他层面：GET可以被缓存、被存储，而POST不行；
            
    Cookie 和 Session（HTTP的附加状态）
        Cookie简介
            1.Cookie是由服务器发给客户端的特殊信息，以文本的形式存放在客户端；
            2.客户端再次请求时，会把Cookie回发；
            3.服务器接受到后，回解析Cookie生成与客户端相对应的内容；
            
        Session简介
            1.服务器端的机制，在服务器上保存的信息
            2.解析客户端请求并操作session id，按需保存状态信息
        
        Session的实现方式
            1.cookie：在cookie中保存JSESSIONID
            2.URL回写：
        
        Session的几种保存方式
            file - 将 Session 保存在 文件 中。
            cookie - Session 保存在安全加密的 Cookie 中。
            database - Session 保存在关系型数据库中。
            memcached / redis - Sessions 保存在其中一个快速且基于缓存的存储系统中。
            array - Sessions 保存在数组中，不会被持久化。
            
        Cookie 和 Session 的区别
            1.Cookie数据存放在客户的浏览器上，Session存放在服务器上
            2.Session相对于Cookie更安全
            3.若考虑减轻服务器负担，应当使用Cookie
        
    HTTPS简介
        在HTTP的基础上加入了SSL/TLS安全层；
        
        SSL(Security Sockets Layer,安全套接层)：
            1.为网络通信提供安全及数据完整性的一种安全协议；
            2.是操作系统对外的API，SSL3.0后更名为TLS；
            3.采用身份验证和数据加密保证网络通信的安全和数据的完整性；
            
        加密方式：
            对称加密：加密解密使用同一个密钥；
            非对称加密：加密解密的密钥不同；
            哈希算法：将任意长度的信息转换为固定长度的值，算法不可逆；
            数据签名：证明某个消息或者文件是某人发出/认同的；
        
        HTTPS数据传输流程：
            1.浏览器将支持的加密算法信息发送给服务器；
            2.服务器选择一套浏览器支持的加密算法，以证书的形式回发浏览器；
            3.浏览器验证证书合法性，并结合证书公钥加密信息发送给服务器；
            4.服务器使用私钥解密信息，验证哈希，加密响应消息回发浏览器；
            5.浏览器解密响应消息，并对消息进行验真，之后进行加密交互数据；
        
        HTTP和HTTPS的区别：
            1.HTTPS需要到CA申请证书，HTTP不需要；
            2.HTTPS密文传输，HTTP明文传输；
            3.连接方式不同，HTTPS默认使用443端口，HTTP使用80端口；
            4.HTTPS = HTTP+加密+认证+完整性保护，较HTTP安全；
            
        HTTPS真的安全吗
            浏览器默认填充http://，请求需要进行跳转，有被劫持的风险
            可以使用HSTS优化
    
    Socket简介
        在交互中，需要每个进程都有一个唯一标识，socket就是网络层面的进程的唯一标识：
        由 IP地址，协议和端口组成；
        
        Socket通信流程：socket(ip地址,协议,端口)
            1.服务端：
                创建socket();
                并绑定socket和接口(bind());
                最后监听端口(listen())
            2.客户端：
                创建socket；
                连接指定计算机的端口(connect())；
            3.服务器：
                接收来自客户端的连接请求accept();
            4.客户端：
                向Socket中写入信息send();
            5.服务端：
                从socket中读取字符recv();
            6.客户端关闭，服务端关闭；