网络基础总结

一、网络分层

TCP的四层：
    一、应用层： 规定向用户提供应用服务时通信协议。 如DNS
    二、传输层： 提供处于网路连接中两台计算机之间的数据传输所使用的协议。在传输层有两个性质不同的协议TCP和UDP
    三、网络层： 规定了数据通过怎么样的传输路线到对方计算机传送给对方。如IP协议
    四、链路层： 用来处理连接网络硬件的部分，包括操作系统、硬件设备的驱动、网卡等

二、TCP
1.简介
    TCP是传输控制协议，基于TCP的应用层有HTTP、SMTP、FTP协议等
2.特点
 面向连接、面向字节流、全双共通道、可靠。
      面向连接：使用TCP传输数据前，必须先建立TCP连接，传输完成后在释放连接
      全双共通道：建立TCP连接后，通信双方都能发送数据
      可靠：通过TCP连接传送的数据：不丢失、无差错、不重复、按序到达
      面向字节流：数据以流的形式进行传输
    3.优缺点
      优点：数据传输可靠
      缺点：效率慢（因需建立连接、发送确认包等）
    4.建立连接  3次握手
      第一次握手：客户端向服务器发送一个连接请求的报文段。报文段信息包括：同步标志位(SYN)设为1、随机选择一个起始序号(seq)为x、不携带数据。客户端进入同步已发送状态(SYN_SEND),等待服务器的确认
      第二次握手：服务器收到请求连接报文段后，若同意建立连接，则向客户端发回连接确认的报文段。报文段信息包括：同步标志位(SYN)设为1、确认标记位(ACK)为1、随机选择一个起始序号(seq)为y、确认号字段(ack)为x+1、不携带数据。服务器进入同步已接受状态(SYN_RCVD)
      第三次握手：客户端收到确认报文字段后，向服务器再次发出连接确认报文段。报文段信息包括：确认标记位(ACK)为1、序号(seq)为x+1、确认号字段(ack)为y+1、可携带数据。客户端、服务段都进如已创建状态，可开始发送数据

注意：成功进行TCP的三次握手后，就建立一条TCP连接，可传送应用层数据。
        因为TCP提供的全双工通信，故通信双发的应用进程在任何时候都能发送数据。三次握手期间，任何一次未收到对面的回复，则都会重发。
    5.为什么TCP建立连接需要三次握手？
        防止服务器端因接收了早已失效的连接请求报文，从而一只等待客户端请求，最终导致形成死锁、浪费资源。
        描述如下：
            a.客户端发出的第一个连接请求报文段无丢失，而是在某个网络结点长时间滞留了，导致延误到连接释放后的某个时间才到达服务器。
            b.导致延误到连接释放后的某个时间才到达服务器
            c.这是一个早已失效的报文段，但是服务器不知道，服务器收到此失效的连接请求报文段后，就误以为是客户端再次发出的一个新的请求，于是向客户端
              发出了确认报文段，同意建立TCP连接
            d.假设不采用“三次握手”，即服务器发出确认报文段后，TCP连接就建立了，但由于客户端并无发出建立连接的请求，因此不会向服务器发送数据，因对                于客户端来说，该报文已失效了，但是服务器却以为新的TCP连接已建立，于是一直等待客户端发送数据，即死锁状态
            e.建立连接= 采用“三次握手”，即关键是第三次握手。
            f.在上面的情况，客户端不会向服务器的确认报文信息，再次发出确认。服务器由于收不到客户端的确认信息，即知道客户端并无要求建立TCP连接，故                服务器不会一直等待客户端发送数据，即不会形成死锁状态
        其他的：SYN洪泛滥：服务器的TCP资源分配时刻=完成第二次握手时，而客户端的TCP资源分配时刻 = 完成第三次握手时，这使得服务器易于受到SYN洪泛攻          击，即同时多个客户端发起连接请求，从而需进行多个请求的TCP连接资源分配。
    6.断开需要四次挥手
        在通信结束后，双方都可以释放连接，共需四次握手。
        释放TCP连接前。TCP客户端、服务器都处于已创建状态（ESTABLISHED），直到客户端主动关闭TCP连接
        第一次挥手：客户端向服务器发起一个连接释放的报文段（停止在发送数据）。报文段信息：终止控制(FIN)设为1、报文段序号，设为前面传送数据最后一个            字节的序号加1（seq = u）,可携带数据（FIN = 1的报文几时不携带数据也消耗一个序号）。客户端进入终止等待1状态。（FIN-WAIT-1）
        第二次握手：服务器收到连接释放报文段后，则向客户端发回连接释放确认的报文段。报文段信息：确认标记位设为1: ACK=1、报文段序号，设为前面传送            数据最后一个字节的序号加1（seq = v），确认号字段设为：ack= u+1。服务器进入关闭等待状态（CLOSE-WAIT）,客户端收到服务器的确认后，进入            终止等待2状态（FIN-WAIT-2），等待服务器发出释放连接请求。至此，客户端->服务器的TCP连接已断开，即TCP连接处于半关闭的状态，即客户端->            服务器断开，但服务器->客户端未断开
        第三次握手：若服务器已无要向客户端发送数据，则发出释放连接的报文段。报文段信息：终止控制(FIN)设为1、确认标记位设为1：ACK=1，报文段序号，            设为（seq = w）,重复上次已发送的确认号字段设为：ack = u+1、可携带数据（FIN = 1的报文即使不携带数据也消耗一个序号）。服务器进入最后确            认状态（LAST-ACK）
        第四次握手：客户端收到连接释放报文段后，则向服务器发回连接释放确认的报文段。报文段信息：确认标记位设为1:ACK=1、                                报文段序号：seq = u + 1、确认号字段为：ack = w + 1、可携带数据（FIN = 1的报文几时不携带数据也消耗一个序号）。 客户端进入等待时间状            态（TIME-WAIT），服务器进入关闭状态（COLSE），此时TCP连接还未释放，必须经过时间等待计时器设置的时间2MSL后，客户端才进入连接关闭状态            （CLOSED），即服务器进入关闭状态比客户端要早一些。

7.为什么TCP释放连接需4次挥手？
        为了保证通信双方都能通知对方。需释放和断开连接。
        当主机1发出“释放连接请求”、主机2返回“确认释放连接”信息时，只表示主机1已无数据要发送到主机2，但主机2还是可以发送数据给主机1，主机1还是可以          接受主机2的数据，即单向断开    
        当主机2也发送了“释放连接请求”、主机1返回“确认释放连接”信息时，表示主机2已无数据要发送到主机1，此时双发都无法通信，即TCP连接才算真正释放          （双向）

8、为什么客户端关闭连接前要等待2MSL时间？
        即TIME-WAIT状态的作用是什么？MSL = 最长报文寿命（Maximum Segment Lifttime）
        原因1:为了保证客户端发送的最后一个请求连接释放确认报文能到达服务器，从而使得服务器能正常释放连接。解析：如下：
             a.客户端发送的最后一个连接释放确认报文可能会丢失，当服务器收不到最后一个连接释放确认报文时，则不会进入关闭状态，但会超时重发，连接释放报文。    
             b.假设：客户端不等待2MSL时间就直接进行关闭状态（CLOSED），当最后一个连接释放确认报文丢失、服务器重发连接释放报文时，客户端则无法接收到服务器重新发送的连接释放报文时，客户端则无法接收到服务器重新发送的连接释放报文，因此也不会发送连接释放确认报文段，最终导致服务无法进入关闭状态（CLOSED）。
            c。客户端发送最后一个连接释放确认后哦，先等待2MSL时间，在进入关闭状态（CLOSE），此时客户端则接收到服务器重新发送的连接释放报文，从而发送连接释放确认报文段，会重新启动2MSL计时器，使得服务器能正常进入关闭状态（CLOSED）
        原因2:防止上文提到的早已失效的连接请求报文出现在本连接中，客户端发送了最后一个连接释放请求确认报文后，再经过2MSL时间，则可使本连接持续时间内所产生的所有报文段都从网络中消失。即在下一个新的连接中就不会出现早已失效的连接请求报文。、

9.TCP无差错传输？
        相对于UDP，TCP的传输是可靠的、无差错的。
        对于发送端：每收到一个确认帧，发送窗口就向前滑动一个帧的距离，当发送窗口内无可发送的帧时（即窗口内的帧全部是已发送但未收到确认的帧），发送方就会停止发送，直到收到接收方发送的确认帧使窗口移动，窗口内有可以发送的帧，之后才可以继续发送。
        对于接收端：当收到数据帧后，将串口向前移动一个位置，并返回确认帧，若收到的数据落在窗口之后，则一律丢弃。

发送窗口：定义：任意时刻，发送方维持的一组连续的、允许发送帧的帧序号。作用：对发送方进行流量控制。
        接收串口：定义：任意时刻，接收方维持的一组连续的、允许接收帧的帧序号。作用：控制可接收哪些数据，不可接收哪些数据帧；接收方只有当收到的数据的序号落入接收窗口内才允许将该数据帧手下；否则，一律丢弃。

10.TCP和UDP的区别
        TCP：面向连接、可靠、字节流（传输形式）、传输速率慢、所需资源多、要求通信数据可靠，首部字节在20-60
        UPD：无连接、不可靠、数据报文段（传输形式）、传输速率快、所需资源少、要求通信速度快，首部字8个字节（由4个字段组成）

二、UDP
    1.面向无连接
    UDP是不需要和 TCP 一样在发送数据前进行三次握手建立连接的，想发数据就可以开始发送了。并且也只是数据报文的搬运工，不会对数据报文进行任何拆分和拼接操作。
    具体来说：

a.在发送端，应用层将数据传递给传输层的 UDP 协议，UDP 只会给数据增加一个 UDP 头标识下是 UDP 协议，然后就传递给网络层了

b.在接收端，网络层将数据传递给传输层，UDP 只去除 IP 报文头就传递给应用层，不会任何拼接操作

2.不可靠性
      a.不可靠性体现在无连接上，通信都不需要建立连接，想发就发。
     b.收到什么数据就传递什么数据，并且也不会备份数据，发送数据也不会关心对方是否已经正确接收到数据了。

c.网络环境时好时坏，但是 UDP 因为没有拥塞控制，一直会以恒定的速度发送数据。即使网络条件不好，也不会对发送速率进行调整。这样实现的弊端就是在网络条件不好的情况下可能会导致丢包，但是优点也很明显，在某些实时性要求高的场景（比如电话会议）就需要使用 UDP 而不是 TCP。

3.高效
    UDP 的头部开销小，只有八字节，相比 TCP 的至少二十字节要少得多，在传输数据报文时是很高效的。
    UDP 头部包含了以下几个数据
两个十六位的端口号，分别为源端口（可选字段）和目标端口
整个数据报文的长度
整个数据报文的检验和（IPv4 可选 字段），该字段用于发现头部信息和数据中的错误
    4.传输方式
        UDP 不止支持一对一的传输方式，同样支持一对多，多对多，多对一的方式，也就是说 UDP 提供了单播，多播，广播的功能。

三、HTTP
    1.简介和特点
        http：超文本传输协议，完成从客户端到服务器等一些系列运作流程。web是建立在http协议上的通信。
        特点：a.http是不保存状态的协议，既无状态协议。协议本身对于请求或响应之间的通信状态不进行保存，因此连接双方不能知晓对方当前的身份和状态。这也是Cookie技术产生的重要原因之一：客户端的状态管理。浏览器会根据从服务器端发送的响应报文内 Set-Cookie 首部字段信息自动保持 Cookie。而每次客户端发送 HTTP 请求，都会在请求报文中携带 Cookie，作为服务端识别客户端身份状态的标识。
             b.无连接，即交换http报文前，不需要建立HTTP连接
        http协议是TCP/IP协议的一个子集.http采用TCP作为运输层协议。
     2.http请求报文。
        http的请求报文有请求行、请求头、请求体组成
        请求行： 声明请求方法、主机域名、路径资源、协议版本
        请求头：声明客户端、服务器、等报文的部分信息
        请求体：存放需发送的数据信息
        报文结构如下：

2.1请求行
        请求行： 声明请求方法、主机域名、路径资源、协议版本
        注意空格不能省略
    请求方法：
        GET：请求读取url标志的信息
        POST：为服务器添加信息
        HEAD：请求读取URL标志信息的首部信息
        PUT：指定的URL下添加（存储）一个文档
        DELETE：删除指定URL所标志信息
        TRACE：用于进行环回测试的请求豹纹
        CONNECT：用于代理服务器
        OPTION： 请求选项信息
    请求路径（URL的地址部分）
        定义：统一资源定位符，
        作用：表示资源位置
        组成：协议：// 主机：端口/路径
    协议版本：
        作用：定义http的版本号
        常见的有HTTP HTTP1.0 HTTP1.1 HTTP2.0 HTTP3.0
请求地址址:Request URL:https://ss1.bdstatic.com/5eN1bjq8AAUYm2zgoY3K/r/www/cache/static/protocol/https/soutu/img/camera_new_5606e8f.png
请求方法 Request Method:GET
远程地址:Remote Address:14.152.86.32:443
状态码:Status Code：304
版本:HTTP/2.0
Referrer 政策 Referrer Policy:unsafe-url
    2.1请求头
        作用：声明客户端、服务器的报文的部分信息
        使用方式：字段名：值
        常用的请求和响应报文的通用Header
通用字段 作用
Content-Type   请求体/响应体的类型。如text/plain、application/json
Accept  说明接收的类型，可以多个值。用,(半角号)分开
Content-Length  请求/响应体的长度，单位字节
Cache-Control  取值一般为no-cache 或 max-age=xx， xx为整数，表示该资源缓存有效期（秒）
Ttag  给当前资源的标识别，和last-nodified、If-None-Match、If-Modified-Since配合，用于缓存控制
Connection 浏览器想要优先使用的连接类型，比如 keep-alive
Date 创建报文时间
Transfer-Encoding 传输编码方式
Upgrade 要求客户端升级协议
    常见的请求头
请求首部 作用
Authorization  用于设置身份认证信息
Accept-Encoding 能正确接收的编码格式列表
Host 服务器的域名和端口号
If-Modified-Since  值为上一次服务器返回的Last-modified值，用于确认某个资源是否被更改过，没有更改返回 304（比较时间）就重缓存里面拿
If-None-Match  值为上一次服务器返回的Etag值，一般会和if-modified-since一起出现
User-Agent 客户端信息
Cookie
已有的cookie
Referer  表示请求引用自哪个地址，比如你从页面A跳转到页面B时，值为页面A的地址。
Host  请求端口
TE
传输编码方式
Accept-Encoding 能正确接收的编码格式列表
Accept-Language
能正确接收的语言列表

Host: ss1.bdstatic.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:66.0) Gecko/20100101 Firefox/66.0
Accept: image/webp,/
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate, br
Referer: https://ss1.bdstatic.com/5eN1bjq8AAUYm2zgoY3K/r/www/cache/static/protocol/https/soutu/css/soutu.css
Connection: keep-alive
If-Modified-Since: Mon, 07 Nov 2016 07:51:11 GMT
If-None-Match: "287-540b1498e39c0"
Cache-Control: max-age=0
TE: Trailers
    2.3请求体                    
    作用：存放 需发送给服务器的数据信息
    注意： get无请求体

3.http响应报文
        响应报文包括：状态行、响应头、响应体
        状态行： 声明协议版本、状态码描述
        响应体：声明客户端、服务器报文部分信息
        响应体： 存放需发送的数据信息

3.1状态行
        组成： 协议版本、状态码、状态信息组成 注意：空格不能省 和（\r\n）
        状态码后面单独讲
    3.2响应头
        作用：声明客户端、服务器报文的部分信息
        使用方式： header：value
响应首部 作用
Date  服务器日期
Last-modified  资源最后被修改时间
ETag 资源标识
Transfer-Encoding  取值一般为chunked，出现在Content-Lenght不能确定的情况下，表示服务器不知道响应版本的数据大小，一般同时还会出现Content-Encoding响应头
Set-cookie  设置cookie
Location  重定向到另外一个URL，如输入浏览器就输入baidu.com回车，会自动跳转到https://www.baidu.com.就是通过这个响应头控制的
Server  后台服务器

4.http状态码
        1xx：表示信息通知，如请求收到了或正在处理
        2xx：表示成功，如接收或者直到了
        3xx：表示重定向，如要完成请求还必须采取进一步行动
        4xx：表示客户端端错误，请求包含语法错误/无法实现
        5xx：表示服务器，服务器不能实现一种明显无效的请求
        
        200->ok
          请求已成功，请求所希望的响应头或数据体将随此响应返回。实际的响应将取决于所使用的请求方法。在GET请求中，响应将包含与请求的资源相对应的实体。在POST请求中，响应将包含描述或操作结果的实体。
        202-> Accepted
          服务器已接受请求，但尚未处理。最终该请求可能会也可能不会被执行，并且可能在处理发生时被禁止。    
        301 -> Moved Permanently 请求的资源已被永久移动到新的位置
           被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个URI之一。如果可能，拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。[19]除非额外指定，否则这个响应也是可缓存的。 新的永久性的URI应当在响应的Location域中返回。除非这是一个HEAD请求，否则响应的实体中应当包含指向新的URI的超链接及简短说明。 如果这不是一个GET或者HEAD请求，那么浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。 注意：对于某些使用HTTP/1.0协议的浏览器，当它们发送的POST请求得到了一个301响应的话，接下来的重定向请求将会变成GET方式。
         302 -> Found 请求的资源被临时移动到新的位置
            要求客户端执行临时重定向（原始描述短语为“Moved Temporarily”）。[20]由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。 新的临时性的URI应当在响应的Location域中返回。除非这是一个HEAD请求，否则响应的实体中应当包含指向新的URI的超链接及简短说明。 如果这不是一个GET或者HEAD请求，那么浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。 注意：虽然RFC 1945和RFC 2068规范不允许客户端在重定向时改变请求的方法，但是很多现存的浏览器将302响应视作为303响应，并且使用GET方式访问在Location中规定的URI，而无视原先请求的方法。[21]因此状态码303和307被添加了进来，用以明确服务器期待客户端进行何种反应。
        304 -> Not Modified
            表示资源在由请求头中的If-Modified-Since或If-None-Match参数指定的这一版本之后，未曾被修改。在这种情况下，由于客户端仍然具有以前下载的副本，因此不需要重新传输资源。
        400 -> Bad Request
            明显的客户端错误（例如，格式错误的请求语法，太大的大小，无效的请求消息或欺骗性路由请求），服务器不能或不会处理该请求。
        401 -> Unauthorized 请求需要验证用户
        403 -> Forbidden 不允许访问该地址
            HTTP 403 服务器已经理解请求，但是拒绝执行它。与401响应不同的是，身份验证并不能提供任何帮助，而且这个请求也不应该被重复提交。如果这不是一个HEAD请求，而且服务器希望能够讲清楚为何请求不能被执行，那么就应该在实体内描述拒绝的原因。当然服务器也可以返回一个404响应，假如它不希望让客户端获得任何信息。
        404 -> not Found 
            求失败，请求所希望得到的资源未被在服务器上发现，但允许用户的后续请求。[35]没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如服务器知道情况的话，应当使用410状态码来告知旧资源因为某些内部的配置机制问题，已经永久的不可用，而且没有任何可以跳转的地址。404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。 
        408 -> Request Timeout 请求超时
            客户端没有在服务器预备等待的时间内完成一个请求的发送，客户端可以随时再次提交这一请求而无需进行任何更改
        500 -> 服务端内部错误       
            通用错误消息，服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。没有给出具体错误信息。 
        502 -> bad gateway
            网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。

5.http2.0 /http3.0
        http2.0