Java学习笔记——网络原理2

应用层

DNS

​ 如果IP地址的形式来访问网站，这种形式难以记忆而且繁杂。于是有大佬就想到了用域名映射IP地址的方式来访问网站。

​ 比如百度的IP地址是1.1.1.1，那么就用www.baidu.com->1.1.1.1来进行映射，大家只要输入www.baidu.com就可以访问百度网站。

早期是使用host文件(弃用)来保存域名与服务器IP的映射，但是缺点也很明显，随着越来越多网站的上线，越来越多用户出现，host文件的更新就显得非常难堪。于是就有大佬想到了用DNS服务器来代替host文件，但是单靠单租DNS服务器是难以满足全球用户的需求的，所以DNS开发者要求各个地区的网络代理商都镜像一个DNS服务器，而DNS根服务器继续在自己麾下，这样不但降低DNS服务器压力，而且实现了高并发高可用。

​ 节流，实现高可用：用户访问网站是很频繁的，为了DNS服务器的负载，会在用户的设备下搞缓存，保存用户访问过的网站。比如某个用户要在一分钟内访问百度十次，那么只需要把第一次DNS请求的结果保存在本地，剩余的九次就可以根据本地保存的文件来访问网站了。

正向代理和反向代理

• 正向代理：指的是代理客户端
• 反向代理：指的是代理服务器

HTTP

HTTP报文请求

下面是HTTP请求

• 首行：1. 方法(GET,POST等) 2. URL(唯一资源定位符，描述了一个资源在网络上的位置) 3. 版本号
• 请求头(Header)：是一个键值对结构的数据，每个键值对独占一行，键和值直接用"冒号和空格"区分
• 空行：表示HTTP请求结束
• 正文：有的HTTP请求有，有的没有

GET//方法 https://api.bilibili.com/x/polymer/pc-electron/live-ups //这个是URL HTTP/2   //这个是版本号   
host: api.bilibili.com //这部分以下，包括这部分都是请求头
accept: */*
accept-encoding: gzip, deflate, br
accept-language: zh-CN
referer: https://www.bilibili.com/client
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: same-site
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) bilibili_pc/1.13.5 Chrome/106.0.5249.199 Electron/21.3.3 Safari/537.36
origin: https://www.bilibili.com
sec-ch-ua: "Not;A=Brand";v="99", "Chromium";v="106"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
x-app-version: 1.13.5
cookie: buvid3=42119C7B42015F3D385DA1C0220722225ZoavyVrStBDaS2xtG1vNQ; innersign=0; fingerprint=040e0436f2cf15166b0a8176c8da3123; buvid_fp=42119C7B42015F3D385DA1C0220722225ZoavyVrStBDaS2xtG1vNQ; buvid_fp_plain=undefined; sid=5dnq8wdu; _uuid=38C49174-8936-B14D-55B1-DAAC85F7F102D76955infoc; buvid4=0BD9E1BE-0D6E-F3C7-67C5-144E259DB33B77075-022072720-GMPl4U33TjlWeFU4Uyoe8g%3D%3D; PVID=10; device_id=bd46a2f2-6365-2b42-8c47-efd89fa72170; mobi_app=pc_electron; platform=web; device=win; b_lsid=25B8AE48_18499B04B1E; LIVE_BUVID=AUTO8516864736479610; CURRENT_PID=986086b0-77db-11ee-93f4-b121e83a67d4; CURRENT_QUALITY=80; SESSDATA=21d7fc96%2C1731716929%2C2a0de%2A52CjDIWooaoFRWIiPHz1bcvErbIaehTzANC9xUsmuUa4hTrB5MbprJkN6A35pZmdgxJPYSVnE3LTUwMF9qeUkyQ1ZlTUFzMFB2aF9DZkZNSENRaDdCTzBIY3N5VVRsVHU4UjdJcE1BMnJRTktSV1J1SUtLTnNNbUhIeW96eDJfNUNPQm5xZVlNTlpnIIEC; bili_jct=88fe45ec7f347f0858ff1c916952b716; DedeUserID=122382881; DedeUserID__ckMd5=ff3257acbd6b11b9; b_nut=1658924277; CURRENT_FNVAL=16
    //这一行是空的，表示HTTP请求结束
//这个HTTP请求报文没有body

下面是HTTP响应

• 首行：1. 版本号 2. 状态码 3. 状态码描述
• 响应头(Header)：是一个键值对结构的数据，每个键值对独占一行，键和值直接用"冒号和空格"区分
• 空行：响应头的结束标志
• 正文：正文内容比较长，可能是文本，也可能是HTML，css，JavaScript，视频，图片，音频等

HTTP/1.1//这个是版本号 200//这个是状态码 OK//这个是状态码描述  
Bdpagetype: 3//下面到空行都是响应头
Bdqid: 0xcf0dc6b0003f6f90
Content-Encoding: br
Content-Security-Policy: frame-ancestors 'self' https://chat.baidu.com http://mirror-chat.baidu.com https://fj-chat.baidu.com https://hba-chat.baidu.com https://hbe-chat.baidu.com https://njjs-chat.baidu.com https://nj-chat.baidu.com https://hna-chat.baidu.com https://hnb-chat.baidu.com http://debug.baidu-int.com;
Content-Type: text/html
Date: Wed, 22 May 2024 02:14:00 GMT
Server: BWS/1.1
Set-Cookie: BD_CK_SAM=1;path=/
Set-Cookie: PSINO=6; domain=.baidu.com; path=/
Set-Cookie: BDSVRTM=10; path=/
Strict-Transport-Security: max-age=172800
Traceid: 1716344040137971815414919799599769022352
Vary: Accept-Encoding
X-Ua-Compatible: IE=Edge,chrome=1
X-Xss-Protection: 1;mode=block
Content-Length: 193

0��R�v���\�iU���n&f'�>���m�Q'n'<|��4������1C5Aޮ��Nh۔�<'�M���9Hd��(�i��oY�<����{�……………………………………//这里省略N多个body内容

• 协议方案名：比如http和https
• 登录信息(认证)：现在很少用了，因为不安全，在程序员开发过程中可能用到
• 服务器地址：一般是服务器的域名地址，但也可以用IP地址
• 服务器端口号：一般是协议的端口，对于http请求是80端口，https是443端口
• 带层次的文件路径：看起来像是目录形式的资源，但是也可能是内存资源，还可能是CPU计算出来的数据。
• 查询字符串(enquire string)：是一种键值对结构的数据，键值对直接用"&“分割，以”?“开头，键和值直接用”="分割。一个url中的query string里可以包含N哥键值对，甚至可能很长。这个一般是程序员自定义的，相当于是用来对这次请求的补充说明。
• 片段标识符：如果网页内容比较长就可以对内容进行分段，通过片段标识就可以在页面内部完成跳转(比如有个博客分成三部分，每个部分都有一个片段标识符，要跳转到下一个内容可以用滚轮也可以修改片段标识符)。

对于query string中的特殊符号请求，例如"+“号，会通过urlencode转化成”%2B"，所以"C++“就被转化成"C%2B%2B”(可以搜索urlencode转换工具来查询转换)

HTTP常用方法

虽然HTTP有很多方法，但是最常用的就是GET和POST方法

POS和GET

​ GET方法常用于获取服务器上的某个资源，通常情况下GET请求中是不带有body的，GET经常是把传递给服务器的数据放到query string中。

​ POST方法常用于提交数据(登录+上传)，POST通常情况下是将数据存放到body中。

​ 注意！以上是建议用法，其实POST和GET完全可以相互代替的，GET可以有body，POST也可以将数据放到query string中，但是极不推荐这样做，因为这样的话就要修改服务器和客户端的约定，而且常用的API都是默设POST的数据存储在body中，GET的数据存在query string中的！

​ 对于某些错误的说法：

1. “GET请求能传递的数据量有上限，POST传递的数据量没有上限”——早期浏览器版本针对GET请求的URL的长度做了限制，实际上RFC标准文档中并没有明确规定URL能有多长，目前的浏览器和服务器的实现过程中，URL可以非常长甚至于传输视频和图片这样的数据。
2. “GET请求传输数据不安全，POST请求传输数据更安全”——他们的根据是GET请求会在登录的时候把账号密码等一些需要保密的数据放到URL中，而POST请求是放到body中，所以更安全。但是他们这里说的更安全其实并不准确，其实真正的安全是不容易被黑客获取或者被黑客获取后不容易被破解。不是不能，而是不容易被破解，比如对账号密码进行加密处理。
3. “GET只能传输文本数据，POST可以给服务器传输文本和二进制数据。”——首先GET也不是不能使用body，其次GET也可以把二进制数据进行base64转码，放到URL的query string中。

幂等性：比如一头牛吃进去的是草出来的是奶，今天是这样明天也是这样，不会改变，那么就是幂等的，如果不同时段出来的东西不一样，那就不是幂等的。

​ 对于某些情况不能说是错的，只是RFC文档建议这么实现：

1. “GET请求是幂等的，POST请求不是幂等的”：无论对同一URL发出多少次GET请求，结果都是相同的。而POST请求不是幂等的，当对同一个URL发出多次请求，可能每次得到的结果都是不一样的。但是！有一种情况，搜索引擎搜索的时候会弹出广告，这些广告使用的是GET方法，但是这些GET请求在设计的时候一定不是幂等的，而是根据用户的信息和时间等设计复杂的逻辑。
2. “GET请求可以被浏览器缓存，POST不可以被缓存”——这个也是幂等性的延续，如果请求是幂等的自然就可以被缓存。
3. “GET请求可以被收藏夹收藏，POST不行(收藏的时候body可能会丢失)”——这种说法大体上是对的，和技术关系不大，主要看用户需求。

认识Header

​ 这里的请求头很多，我们这里主要列举常用的几个。

1. Host：描述了服务器所在的IP和端口号(在url中也存在，但是不一定和Host完全一样，比如在使用代理的时候Host和url内的就可能不一样)
2. Content-Length：body中数据的长度(请求里有body才有这个属性，通常情况下GET请求没有body，POST请求有body)
3. Content-Type：body中数据的格式(请求里有body才有这个属性，通常情况下GET请求没有body，POST请求有body)，常见的格式请求中主要有json，form表单，form-data；响应中主要有html，js，css，json，图片。浏览器会根据不同的Content-Type做出不同的处理。
4. User-Agent(简称UA)：描述了用户使用什么设备上网，会显示操作系统版本和浏览器版本。一般是用来区分用户是PC端还是移动端
5. Reference：描述用户是从哪个页面跳转过来的(如果是直接从地址栏输入url或者点击收藏夹按钮就没有Reference)，可以用来进行商业，比如在广告统计的时候就可以知道哪些用户是从A网站跳转的，哪些用户是B网站跳转的。(CPC广告)
6. Cookie：可以认为是浏览器在本地存储数据的一种机制。浏览器的数据来源于服务器，浏览器的后续操作也要提交给服务器。服务器这边管理了网站的各种核心数据。但是程序在运行过程中会有一些数据，需要在浏览器这边存储，并在下次请求时再发送给服务器。(比如上次登录时间，上次访问时间，登录信息，累计访问次数等)，这些是临时性数据，存储在浏览器比较合适。Cookie是按照键值对的方式组织的，这里的键值对和query string一样，也是由程序员自定义的。Cookie一般是以网站为单位，每个网站都有自己的Cookie。

响应与状态码

​ 20x：以20开头的一般表示成功，例如200表示OK

​ 301：永久重定向，比如网站A的网站原本是www.A.com，现在A永久搬迁到了网页地址为www.AA.com，那么下次再访问原来的网页时候返回的状态码为301，表示永久重定向。

​ 302：临时重定向，相对于301而言302是临时的，就是会搬迁会www.A.com的。(临时重定向一般不被缓存)

​ 404：Not Fount 表示请求的资源在服务器上不存在，就是访问了服务器上不存在的资源。(永久重定向可以被缓存)

​ 403：Forbidden表示该用户没有权限访问该资源。

​ 5xx：表示服务器出错，看到这个说明服务器可能挂了。我们平时写的时候可能写出500(Internal Server Error)这样的错误，一般就是我们的代码有问题。

触发请求

1. 直接在浏览器地址栏输入url，此时构造了一个GET请求。
2. html中一些特出的标签，可能触发GET请求(例如img，a，link，script等)
3. 通过form表单触发GET/POST请求(form本质也是一个HTML标签)，我们也可以使用ajax来对某个url发送get或post请求

我们也可以通过修改method来使其变成post方法。

运营商劫持

​ 我们发送的HTTP请求要经过运营商路由器，运营商完全可能更改我们的HTTP请求，比如我们下载一个软件它可能直接变成其他的软件(例如一刀9999这种)。

​ 这个也可能被黑客利用进行劫持，比如我们在商店连接了一个陌生奇怪的路由器，如果是黑客的钓鱼陷阱，那他可能就会盗取我们的信息，但是如果像是支付宝密码这样的信息，都是通过加密的。如果这里使用Https更加安全，因为其引入了证书机制，黑客不容易入侵。

HTTPS

​ HTTPS相当于HTTP的升级版，运用了证书来保证通信安全。

首先要怎么保证通信安全呢？

以下例子将A当做客户端，B当做服务端(网站)

1. 使用密钥对称加密，就比如说有一个箱子，箱子上了锁，只有持有钥匙的人才能打开箱子。A和B进行通信，A配备了钥匙，然后将箱子(信息)和钥匙(密钥)一同邮送出去，这时候如果邮递员(被黑客入侵的路由器)心怀不轨，去复刻了一把同样的钥匙，这时候每次A和B用箱子进行通信的时候就会被邮递员知道，信息就不安全了！
2. 使用非对称加密，就是使用一个私钥和一个公钥进行加密。公钥一般是谁都可以拥有的，但是私钥一般是创建的人才能拥有，使用私钥加密，需要使用公钥才能解开得到明文，同理，公钥加密的信息只能由私钥进行解密得到密文。当A要和B进行通信的时候，A创建私钥和公钥，然后将公钥传递给B，B得到公钥后就可以和A进行加密通信了。但是！！！如果途中的路由器有某个被黑客入侵了，而且也保存了一份公钥，黑客能篡改A发送给B的信息——比如A给B发送信息说"今天是晴天"，当信息传输到被黑客入侵的路由器的时候，黑客可以截停A的信息，而将自己的信息发送给B——“今天是阴天”，然后B就以为是A说的，实际上信息已被篡改。
3. 使用对称加密和非对称加密同时加密，就是当A和B刚开始通信的时候，B先创建公钥和私钥，然后将公钥传递给A，接着A创建密钥，并通过公钥B加密密钥，然后传递给B，之后A和B之间利用密钥通信(利用密钥是因为密钥的效率比利用公钥和私钥的高)。

​ 但是这个加密也是有安全风险的！如果被黑客入侵的路由器对A扮演B，对B扮演A，那不就被破了吗？(如下图)

很明显，在这种情况下，这样的通信也会被黑客监听和篡改。

4. 引入证书机制(TLS/SSL)

证书包含内容了数字签名，域名，厂商，过期日期，服务器公钥等。

客户端拿到证书之后会用机构的公钥(装系统的时候就自动下载的)对证书中的数字签名进行解密，得到校验和，然后客户端通过自己计算一次校验和与解密得到的校验和进行比较，如果一致那就说明没有被修改过。然后接着，客户端就可以拿到服务端的公钥，自己生成一个密钥返回给服务器，就可以进行密钥通信了。

1. 黑客是否可以修改数字签名？——不能！如果黑客修改了数字签名，那么客户端就无法通过系统内置的公钥解开这个数字签名，客户端就知道这个证书有问题。
2. 黑客是否可以修改证书中的服务器公钥？——不能，因为如果修改了，客户端计算出来的校验和就和数字签名解密出来的校验和不一致了！
3. 黑客是否可以替换证书？——不能，因为证书上包含了服务器的详细信息，如果客户端访问的域名和被替换的证书的域名不一致，那就说明访问有问题，浏览器会报警告。

Java学习笔记——网络原理1