目录
核心知识回顾
网络编程---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加密后的数据进行解密的.
此时数据到达服务器,服务器使用自己的私钥解密就知道了对称密钥是多少了直接全用非对称加密不行吗??
实际情况是,需要
对称加密,运算速度快,开销小.适合针对大量数据进行加密.
非对称加密,运算速度慢,开销大.加密小的数据,还行.加密大量数据,非常耗时上述方案存在严重漏洞
