Closed draveness closed 2 years ago
Hi, 您好, 請問您文章內的圖片是利用什麼繪圖工具產生的呢?
Hi, 您好, 請問您文章內的圖片是利用什麼繪圖工具產生的呢?
看一下文章结尾?
真不好意思,之前一直沒注意到文章結尾有提到這些資訊。
謝謝。
@edentsai 真不好意思,之前一直沒注意到文章結尾有提到這些資訊。
謝謝。
楼主这个工具强大 同时推荐 OmniGraffle
向客户端发送 Server Key Exchange 消息,传递公钥以及签名等信息;
证书里不是就包含公钥了吗, 这里的公钥应该是传送premaster专用的 Diffie-Hellman公钥吧?
下面摘抄自 rfc5246
This message conveys cryptographic information to allow the client to communicate the premaster secret: a Diffie-Hellman public key with which the client can complete a key exchange (with the result being the premaster secret) or a public key for some other algorithm.
图放大150%看起来清晰
你好,我想问一下,在TLS验证的时候,浏览器这边验证服务器传递的证书域名信息,浏览器是如何识别的,或者说浏览器本身已经存储相对应的域名信息,那么这么大的域名信息如何存储呢?
你好,我想问一下,在TLS验证的时候,浏览器这边验证服务器传递的证书域名信息,浏览器是如何识别的,或者说浏览器本身已经存储相对应的域名信息,那么这么大的域名信息如何存储呢?
浏览器会存一些根证书
“TLS 握手的关键在于利用通信双方生成的随机字符串和服务端的公钥生成一个双方经过协商后的密钥,通信的双方可以使用这个对称的密钥加密消息防止中间人的监听和攻击,保证通信的安全” 我觉得这个好像说得不大对哎,TLS握手还是无法防止中间人攻击,HTTPS还是存在中间人攻击的可能
另外还有个问题,楼主为什么在总结握手次数的时候,没有把http建立连接的次数(两次)计在内,我查了一些资料,没有找到 网络中“握手”的相关定义,期待您的解答~
另外还有个问题,楼主为什么在总结握手次数的时候,没有把http建立连接的次数(两次)计在内,我查了一些资料,没有找到 网络中“握手”的相关定义,期待您的解答~
这里说的是 HTTP 请求前的准备
TLS 第2点第5小点,应该是“通知客户端已经发送了全部......”吧
阅读了您的文章,很有收获,不过在学习其他博客的时候,看到了一个内容基本相同的文章...
如果有参考别人文章的话最好还是加上出处吧
阅读了您的文章,很有收获,不过在学习其他博客的时候,看到了一个内容基本相同的文章...
如果有参考别人文章的话最好还是加上出处吧
不好意思,没看过这个,你这个链接我删了
@draveness
阅读了您的文章,很有收获,不过在学习其他博客的时候,看到了一个内容基本相同的文章...
如果有参考别人文章的话最好还是加上出处吧
不好意思,没看过这个,你这个链接我删了
唉,其实我没有其他的意思,我自己也会写写博客,然后文章写的不好也经常有引用他人博客的内容或是对别人文章的总结摘要甚至是原文搬运,不过我都会在末尾留下文章来源。
我只是觉得,写原创文章真的真的很不容易,既然有搬运内容,那么作为对作者最起码的尊重就是加上引用地址了,然后如果能有自己的补充和梳理,搬运文章真的没什么(个人观点),这样也能帮助到其他人,但是把别人文章说成自己的,我并不认同。
然后我对比了一下计算机网络方面的其他文章,有好多篇内容排版以及文字基本也都是一致的,而且发文日期都比您文章要早...
很抱歉说了这么多,还是希望您多尊重原创。
最后还是谢谢您的一些文章确实有帮助到我。
@yleave
@draveness
阅读了您的文章,很有收获,不过在学习其他博客的时候,看到了一个内容基本相同的文章... 如果有参考别人文章的话最好还是加上出处吧
不好意思,没看过这个,你这个链接我删了
唉,其实我没有其他的意思,我自己也会写写博客,然后文章写的不好也经常有引用他人博客的内容或是对别人文章的总结摘要甚至是原文搬运,不过我都会在末尾留下文章来源。
我只是觉得,写原创文章真的真的很不容易,既然有搬运内容,那么作为对作者最起码的尊重就是加上引用地址了,然后如果能有自己的补充和梳理,搬运文章真的没什么(个人观点),这样也能帮助到其他人,但是把别人文章说成自己的,我并不认同。
然后我对比了一下计算机网络方面的其他文章,有好多篇内容排版以及文字基本也都是一致的,而且发文日期都比您文章要早...
很抱歉说了这么多,还是希望您多尊重原创。
最后还是谢谢您的一些文章确实有帮助到我。
这里的文章什么时候原文搬运过
这文章后面这些 Reference 是白写的么,还『希望我多多尊重原创』
@draveness
阅读了您的文章,很有收获,不过在学习其他博客的时候,看到了一个内容基本相同的文章... 如果有参考别人文章的话最好还是加上出处吧
不好意思,没看过这个,你这个链接我删了
唉,其实我没有其他的意思,我自己也会写写博客,然后文章写的不好也经常有引用他人博客的内容或是对别人文章的总结摘要甚至是原文搬运,不过我都会在末尾留下文章来源。
我只是觉得,写原创文章真的真的很不容易,既然有搬运内容,那么作为对作者最起码的尊重就是加上引用地址了,然后如果能有自己的补充和梳理,搬运文章真的没什么(个人观点),这样也能帮助到其他人,但是把别人文章说成自己的,我并不认同。
然后我对比了一下计算机网络方面的其他文章,有好多篇内容排版以及文字基本也都是一致的,而且发文日期都比您文章要早...
很抱歉说了这么多,还是希望您多尊重原创。
最后还是谢谢您的一些文章确实有帮助到我。
我又看了一眼你说的这个文章,我现在有有点怀疑这个人是不是 Copy 的我的博客,你知道这个文章的日期可以随便改的么?
@draveness
@draveness
阅读了您的文章,很有收获,不过在学习其他博客的时候,看到了一个内容基本相同的文章... 如果有参考别人文章的话最好还是加上出处吧
不好意思,没看过这个,你这个链接我删了
唉,其实我没有其他的意思,我自己也会写写博客,然后文章写的不好也经常有引用他人博客的内容或是对别人文章的总结摘要甚至是原文搬运,不过我都会在末尾留下文章来源。
我只是觉得,写原创文章真的真的很不容易,既然有搬运内容,那么作为对作者最起码的尊重就是加上引用地址了,然后如果能有自己的补充和梳理,搬运文章真的没什么(个人观点),这样也能帮助到其他人,但是把别人文章说成自己的,我并不认同。
然后我对比了一下计算机网络方面的其他文章,有好多篇内容排版以及文字基本也都是一致的,而且发文日期都比您文章要早...
很抱歉说了这么多,还是希望您多尊重原创。
最后还是谢谢您的一些文章确实有帮助到我。
我又看了一眼你说的这个文章,我现在有有点怀疑这个人是不是 Copy 的我的博客,你知道这个文章的日期可以随便改的么?
抱歉,我知道文章日期是可以改的,不过我没往那方向去想
然后我去看了一下这个博客的 repo,果然日期是改的,它的这篇文章实际提交到 github 上的日期比您的要晚
很抱歉没去探究清楚就妄下断言
那就是这个博客的主人有很多文章是照搬您的文章了。
抱歉,我知道文章日期是可以改的,不过我没往那方向去想
然后我去看了一下这个博客的 repo,果然日期是改的,它的这篇文章实际提交到 github 上的日期比您的要晚
很抱歉没去探究清楚就妄下断言
那就是这个博客的主人有很多文章是照搬您的文章了。
GitHub 的 Commit 也是可以改时间的
@yleave 可能你看的文章不够多, @draveness 根本不会搬运。。。
@draveness
抱歉,我知道文章日期是可以改的,不过我没往那方向去想
然后我去看了一下这个博客的 repo,果然日期是改的,它的这篇文章实际提交到 github 上的日期比您的要晚
很抱歉没去探究清楚就妄下断言
那就是这个博客的主人有很多文章是照搬您的文章了。
GitHub 的 Commit 也是可以改时间的
学习了😢 抱歉
@dawncold @yleave 可能你看的文章不够多, @draveness 根本不会搬运。。。
是的,文章还是看少了.
在学习过程中刚好看到基本一致的文章,对比下日期又看到没有引用,本身对搬运有点反感...所以就留冒犯了。
准备工作主要是通过非对称加密将服务端的对称加密的密钥传递给客户端,后期两端的通信就要靠这个对称加密的密钥来支持。因为对称加密的密钥容易被获取,所以不能明文传输。所以用了非对称加密,进行密钥传输。客户端方会用自己的私钥对服务端传来的非对称加密的数据进行解密并获取对称加密的密钥,用于后期的数据传输的加解密。
https://draveness.me/whys-the-design-https-latency
HTTP 协议已经成为互联网上最常用的应用层协议,然而其本身只是用于传输超文本的网络协议,不会提供任何安全上的保证,使用明文在互联网上传输数据包使得窃听和中间人攻击成为可能,通过 HTTP 传输密码其实与在互联网上裸奔也差不多。HTTPS 是对 HTTP 协议的扩展,我们可以使用它在互联网上安全地传输数据,然而 HTTPS 请求的发起方第一次从接收方获取响应需要经过 4.5 倍的往返延迟。本文将详细介绍请求发起和响应的过程,分析为什么 HTTPS 协议需要通过 4.5-RTT 的时间获得服务提供方的响应: