（网络原理）核心知识回顾 网络核心原理 get和post的理解 解析http 加密+请求和响应的一些关键字 Cookie和session 对密钥的理解

目录

核心知识回顾

网络核心原理

get和post的理解

解析http

加密+请求和响应的一些关键字

Cookie和session

对密钥的理解

---

核心知识回顾

网络编程---socket api
UDP DatagramSocket DatagramPacket
TCP ServerSocket    Socket
1.读写数据通过Socket,通过Socket内置的 lnputStream和OutputStream      读写基本单位是字节
2.当前在编写客户端服务器的时候,是需要约定请求/响应之间的分隔符的.(\n)
3.服务器这边accept得到的socket对象,记得及时关闭
4.要处理多个客户端,需要搭配多线程/线程池 

如果客户端进一步增加,此时多线程/线程池,就会产生出大量的线程.
操作系统中内置了IO多路复用--本质上一个线程同时负责处理多个客户端的请求

等到客户端发来数据的时候线程再来处理就可以了.
多个客户端同时发数据的概率比较小

虽然只有一个线程也能处理多个客户端了   万一有3k,3w个客户端,冲突概率大了嘛??
咱又不是说,只有1个线程.多搞一些线程就可以处理更多的客户端了

异步同步是站在客户端的视角看待的.(上游看待下游)
此处1O多路复用是站在服务器的视角.(下游看待上游)

IO多路复用当前开发服务器的主流的核心技术.
操作系统内置的.只需要调用api即可.
Java通过NIO来封装了IO多路复用.

数据组织格式

具体如何自定义协议呢??    自定义协议,分成两个阶段:
1.根据需求,明确传输哪些信息.
2.约定好信息组织的格式.

1）行文本的方式
用户id,用户的位置\n
1000,45E45N\n
一个响应由多行构成,每一行是一个商家,每个商家中包含一些列信息.
以空行来结尾

实际约定的时候,可以有很多变数的，列和列之间,不一定使用,也可以使用;也可以使用.也可以使用\t
多个数据之间,也不一定使用\n,也可以随心所欲使用任何你喜欢的分隔符.........
自定义协议!!你就是说了算的那个
只要客户端和服务器都按照这同一套规则来进行构造/解析数据就行了

2）用来网络传输，和浏览器怎么显示无关.html约定浏览器怎么显示的.

xml可以用于很多场景,组织一段格式化数据     数据用来网络传输,作为配置文件..

xml方案,放到10年前,用的还挺多的.现在,很少用xml进行网络传输了.
优点:可读性好.
缺点:元余信息太多了.网络传输中,消耗更多的带宽

对于服务器来说,带宽是最贵的.硬盘最便宜  内存其次   cpu 小贵

3)json当下最流行的网络数据格式组织的方案.

优点:可读性也是很好的
消耗的带宽,也比刚才谈到的xml更节省
缺点:还是存在冗余信息.

4）protobuf

基于二进制的格式,对数据进行压缩.不涉及到json/xml元余信息了.
带宽消耗最少,可读性就变差了.

protobuf,约定这一段二进制数据  哪几个字节表示那个信息

数据组织格式
1.行文本(最原始)
2.xml(比较原始,可读性好,元余较多)
3.json(主流的方式,可读性好,元余一般)
4.protobuf(高性能场景下使用的方式,可读性差,余最小)

但凡实现一个具体的程序,写代码之前,一定是要先约定应用层协议的格式的

应用层这里,除了自定义协议之外,也有一些大佬们现成搞好的协议了.
FTP文件传输
SSH远程操作主机
telnet 网络调试工具

 HTTP一问一答模式的协议
客户端发一个请求,服务器就返回一个响应
请求和响应一一对应

浏览器打开网页的场景/手机app加载数据的场景
典型的一问一答场景，使用HTTP就非常合适

正向代理(代表客户端干活)
反向代理(代表服务器干活)

你电脑上所有的网络通信,都会先发给这个抓包程序,抓包程序再把数据转发给服务

本身网络传输,就是要经过很多节点转发的.
不在乎间多个一次两次  一般来说是没有影响的
但是不排除特殊软件会产生冲突

网络核心原理

通过fiddler可以做到很多事情的
爬虫本质上就是HTTP的客户端(自己代码实现的)
自己写代码,伪造出差不多的请求,就可以达成类似的功能效果了.
给你自己的博客点赞,互赞朋友自动评论

网络这个东西和操作系统是无关的
windows主机能不能访问linux服务器??必然可以
windows和linux不同的系统,其实是同一套网络规则
遵守相同的网络协议

响应数据,经常是压缩后传输的.   为了节省网络带宽.

MySQL是一个"客户端-服务器"结构的程序.存储数据的本体是在服务器

域名和ip可以相互转换.
这个过程通过DNS域名解析系统来完成的
(DNS既是一套服务器系统,也是一种应用层协议)

通过IP定位到一台主机了.  同一个主机上是有多个程序都在使用网络
通过端口号来进一步区分

转义操作,不仅仅是标点符号,对于中文等其他非英语系的文字,也是需要转义的.
只不过很多浏览器为了用户看起来方便,显示的时候显示转义之前的
实际上抓包中就能看到,是已经转义的数据

urlencode把数据的二进制内容,每个字节取出来十六进制表示,前面加上%

F5刷新,重新访问服务器.    ctrl+F5强制刷新：忽略本地缓存,所有资源都重新从服务器获取
浏览器的缓存机制：浏览器从服务器/通过网络加载网页.(最快cpu,内存,硬盘,网络)
通常情况下,从网络加载数据比从硬盘加载要慢
(如果万兆网卡,除外.充钱)
浏览器为了加快访问页面的速度,就会把页面依赖的一些静态资源(css,js,图片,字体,mp3....)这些内容缓存到硬盘上.
第一次访问服务器,需要加载这么多东西.后续再访问,就不必重新加载

get和post的理解

POST来说 两个典型的场景
1.登录
2.上传=>请求带有正文的.正文就是保存了当前上传的数据的内容
上述请求中,图片本身是二进制的,通过特殊方式进行转码(base64编码,把二进制其实body也是可以直接填二进制数据）

协议名://ip地址(域名):端口号/路径。查询字 

方法GET  POST  PUT  DELETE
Restful api 设计风格

GET和POST区别

面试中被问到了首先先抛出结论,GET和POST没有本质区别,经常是能够混用的

POST也是可以带有query string(还是有一些的)
GET理论上也可以带 body(更少见)
从使用方法习惯上来说,主要是两个方面的区别
1.语义
2.GET经常把数据放到 url的 query string 中.POST经常把数据放到body 中

Host:gitee.com:端口号    当前的请求访问的服务器在哪里
ip地址(域名):端口号
绝大部分情况下,这俩属性也是一致
3.GET请求通常建议设计成幂等的.POST无要求    HTTP标准文档给的建议.
但是只是建议,不是强制要求.    请求一定的,得到的响应也是一定的~~幂等
服务器开发中需要考虑一个环节    尤其是像支付的这样的场景,通常都要考虑幂等性

4.GET设计成幂等了,就可以允许GET请求的结果被缓存.
POST由于不要求幂等,经常是不幂等的,就认为不能被缓存的

实际上现在GET不幂等的情况太常见了.    现在的互联网产品,都讲究"个性化推荐"

1.POST 比GET更安全    登录场景.输入用户名和密码.
GET,用户名密码就会放到url的querystring中,就会显示在浏览器地址栏上了
保证安全,关键是"加密传输
https//gitee.com/HGtz2222?username=xoxx&password=xoox
POST传输如果不加密,黑客随便抓个包,也就看到了.
只要明文传输,都谈不上安全
2.GET传输数据有长度限制
上古时期IE浏览器的年代,IE6(windows xp)对于URL的长度是有限制的
此时传输的数据太多,可能就会被截断.   现在的主流浏览器/服务器早都没有这样的限制了
比较长的URL很多时候也能见到

3.GET只能传输文本,POST可以传输二进制

GET确实url只能放文本.可以把二进制通过base64转码成文本的.
GET也不是完全就不能带body(有些客户端/服务器不支持)

数据部分放哪里
GET 数据放到 url query string  要传输的数据很多,url就会很长
post放到body里,url就可以比较短了

这四个操作的任何一个,都可以进行增删改查
完全是取决于你代码咋写

解析http

HTTP往往是基于传输层的TCP协议实现的.(HTTP1.0,HTTP1.1,HTTP2.0均为TCP,HTTP3基于UDP实现)

当我们在浏览器中输入一个搜狗搜索的"网址"(URL)时,浏览器就给搜狗的服务器发送了一个HTTP请求,搜狗的服务器返回了一个HTTP响应.

这个响应结果被浏览器解析之后,就展示成我们看到的页面内容.(这个过程中浏览器会给服务器发送多个HTTP请求,服务器会对应返回多个响应,这些响应里就包含了页HTML,CSS,JavaScript,图片,字体等信息).
所谓"超文本"的含义,就是传输的内容不仅仅是文本(比如html,css这个就是文本),还可以是一些其他的资源,比如图片,视频,音频等二进制的数据.

请求报头：

加密+请求和响应的一些关键字

HTTP协议中,传输的时候可能会涉及到"加密"(HTTPS)
url 部分是不会被加密的.被加密的是 header 和 body
服务器收到请求之后也就可以做一个最终校验
验证url中的内容和header 中加密的内容是否一致

一般登录密码这种,都是要在业务层加密的
依赖HTTPS这种操作,只能保证传输过程中是安全的.
但是如果密码就明文保存在服务器上,服务器可能会被黑客攻击,严重触发拖库
也会造成密码泄露

HTTP协议,传输层这里基于TCP实现的(版本号<=2.0)

把这一串字符串,写入到tcp socket 中

对于TCP来说,一个连接上可以发多个请求
服务器这边收到数据的时候就得区分一下,从哪里到哪里是一个完整的http请求数据

没有body的http请求,读到空行,就可以认为是结束了.
有body的 http 请求呢?先读取首行和header,读到空行;解析 header 中的Content-Length
根据这里的值,接下来再读取固定字节的长度

UDP中面向数据报的---读写的基本单位就是一个UDP数据报.
某个应用层协议,基于UDP,一个UDP数据报就对应一个完整的应用层数据包.
调用一次receive操作,就得到一个明确的UDP的数据包

前面写tcp代码,next来读取的(隐含了一个约束,使用空白符作为结束标记)

text/html--HTML
浏览器就会解析其中的标签,把标签转换成界面显示
text/css--CSS
浏览器就会解析其中的选择器和属性,并且把这里指定的内容应用到页面的样式上
application/javascript---JS
浏览器通过js引擎解释执行js中的逻辑
application/json--JSON
浏览器不会做任何处理(由对应的js程序员写的逻辑中)
image/png--图片image/jpg
浏览器尝试按照图片的二进制格式,解析出来并显示

C++/Java这样的代码,编译成二进制.  发布给用户.
用户拿到的是二进制代码.用户想根据二进制,还原出原始的源代码是怎样的,非常麻烦的
js这样的代码则是把原始代码直接由用户浏览器下载到.
用户就能看到js的原始的样子

从用户使用的角度来说,没啥区别.，硬件发展达到一定程度了.
对于32位的系统/CPU来说,能够支持的最大内存,4G
15年前,计算机的内存差不多就达到4G了
8G内存的机器,必须的是64位~cpu和操作系统

32位cpu意味着对应的指针变量就是32个blt(多大的内存空间上寻址)
正常来说,32位cpu运行的是32位的程序4GB
64位cpu运行的是64位的程序.

windows兼容做的好.64位的windows系统  也可以无缝的使用32位的程序

同一个时间段内,有些用户的浏览器,版本是比较旧的,支持的功能少
有些用户浏览器版本更新,支持的功能多.
如果要是支持的功能少,可能就打不过竞争对手
如果支持的功能多,旧版本浏览器设备的用户,可能就展示不了

根据用户使用的设备,进行区分.
通过UA中的浏览器版本/操作系统版本,区分出当前用户的设备,最多都支持哪些特性
老的浏览器,返回功能少的网页,正确显示
程序员就需要维护多套代码    新的浏览器,返回功能多的网页,体验丰富

UA还有另外一个用途  可以用来区分用户的设备.
windows/mac=>PC  ios/android=>手机
根据用户的设备,返回不同版本的页面.

Referer    描述了当前页面的来源    这个页面是从哪个页面跳转来的
直接输入url/点收藏栏打开的页面是没有Referer
主页跳到搜索页   Referer:https://www.sogou.com/  搜索页的 referer

是否存在可能,有人把referer给改了.
本来是搜狗的referer 改成别人的referer   2014年的时候,这种情况非常普遍
对于广告平台造成一定的损失

有能力的:用户上网的时候,HTTP请求都是经过运营商的路由器/交换机   通过软件,分析数据流量    把一些广告的数据的HTTP数据报进行修改就行了
有动机的:运营商也有自己的广告平台.(运营商和搜狗/百度是竞争关系)

技术上反制~~=>HTTPS

HTTPS协议能够有效的对HTTP数据报进行加密传输 (referer也被加密了)

Cookie和session

Cookie
浏览器展示页面的过程中,页面里虽然可以通过js来实现一些逻辑
但是js代码无法访问你的硬盘的(文件系统)--浏览器给js带上的紧箍咒
怕js要是能操作用户文件系统再瞎搞的
实际开发中,有的时候还是希望把某些数据能够保存到本地硬盘的
因此浏览器引入了cookie 机制.
cookie就是浏览器允许网页在本地硬盘存储数据的一种机制.
不是让网页代码直接访问文件系统,而是做了一层抽象.而是浏览器的cookie提供了键值对存储机制

有些网站,让用户决定,是否愿意存他的cookie数据

浏览器保存了这些cookie之后,就会在后续给服务器发送请求的时候,把这些cookie键值
Cookie到哪里去:最终发回给服务器.
Cookie从哪里来:也是从服务器这边来的.(后端开发程序员,决定的)

Cookie里的数据都是程序员自定义内容.业务相关的
但是有一个典型的场景,属于"通用业务"   登录和用户认证

 会话---session 对象也是可以存储用户自定义的数据的  表示了当前这一次会话的详细信息

会话就是记录一些重要的信息 

描述了客户端和服务器之间的一种交互关系.
数据库,也是服务器.   对应的客户端,就是你的应用程序/Workbench....
你的这个客户端访问一次数据库服务器,这个中间的过程  也可以称为是一次会话

这个过程.关键数据的状态    会话中记录的内容,只是当前的状态
日志会记录整个变化的过程(之前是啥样的,修改之后又是啥样的)

服务器收到后续请求之后,直接通过cookie 中的sessionld
就可以知道当前这个请求是哪个用户发来的了.  就不需要要求用户重新登陆.

Cookie是可能会过期的.服务器返回Cookie的时候,是可以设置有效时间
如果Cookie 中的sessionld过期了,此时就需要用户重新登陆了.
用户重新登陆的时候,是否需要重新手动输入一遍密码,浏览器的记住密码功能解决的问题了

有的网站,对于安全性要求不高,过期时间就长
有的网站,对于安全性要求很高,过期时间就短
(网银...只要你把页面关闭/几分钟之内不操作,就会自动过期)
在公共电脑上操作,人就离开了---下一个人拿到这个电脑

举个例子：

1.挂号办理一个就诊卡.就需要填写表格,记录一些核心信息  医生把这些信息录入电脑，医生给你一个就诊卡
相当于生成会话.就诊卡只存储一个会话id(卡可能会丢)

2.儿科门诊   刷一下就诊卡     刷卡,医生电脑上就显示出了这个患者的所有信息

医生开了检查---开了一些单子     直接记录到会话中

3.检验科--刷一下就诊卡
检验科的医生立即看到了我这边要查啥
4.影像科--刷一下就诊卡
5.回到儿科诊室--刷一下就诊卡
检查结果,直接显示到医生的电脑上了

通过Java socket构造HTTP请求    HTTP请求,本质上就是TCP请求
只需要构造字符串,符合HTTP协议格式.    写入到TCP socket中

对密钥的理解

HTTPS   加密
HTTPS=HTTP+S(SSL/TLS)    也是一个应用层协议. 专门负责加密.

"加密"是什么
加密就是把明文(要传输的信息)进行一系列变换,生成密文,
解密就是把密文再进行一系列变换,还原成明文.

在这个加密和解密的过程中,往往需要一个或者多个中间的数据,辅助进行这个过程,这样的数据称为密钥

1.对称加密.   加密和解密使用同一个密钥
2.非对称加密  加密使用一个密钥   解密使用另一个密钥

把其中一个公开出去,公钥
另一个自己保存好,私钥

你装了wifi万能钥匙之后自动把你手机中已经保存的wifi和密码上传到服务器
别人用wifi万能钥匙连到同一个wifi上就能破解(获取到之前别人上传的密码)
后来被手机厂商做出限制了

之前是明文传输的：

此时黑客很容易获取到
传输的数据内容,也很容易进行篡改

如果不知道key是啥   就无法对数据进行解密  无法理解数据的含义,更不必说算改了

服务器要给N个客户端提供服务多个客户端,密钥是相同还是不同??必须是不同的!!!

如果大家都是相同的密钥,意味着黑客自己搞个客户端就拿到密钥了
(你的银行卡密码,和我的能一样吗??)

密钥本身是明文传输的~~就可能被黑客获取到

一旦黑客拿到密钥,后续的加密操作就无意义了

公钥是一把锁  私钥是对应的钥匙

基于前人研究出来的加密算法,生成的.(有一系列数学原理)数学上,针对两个非常大的素数,做乘积,很容易的.    根据乘积因式分解回刚才的两个大素数,非常难的
这一对公钥私钥,就是这两个大素数

由于黑客手里没有私钥.   所以黑客不能对888888加密后的数据进行解密的.
此时数据到达服务器,服务器使用自己的私钥解密就知道了对称密钥是多少了

直接全用非对称加密不行吗??
实际情况是,需要
对称加密,运算速度快,开销小.适合针对大量数据进行加密.
非对称加密,运算速度慢,开销大.加密小的数据,还行.加密大量数据,非常耗时

上述方案存在严重漏洞