【已解决】Error in the HTTP2 framing layer

本文主要是介绍【已解决】Error in the HTTP2 framing layer，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1.问题描述

在使用git将代码上传github的时候在最后一部push的时候遇到这个fatal

2.解决方案

由于我原先设置的origin是http协议下的，如下

 git remote add origin https://github.com/Charlesbibi/Simple_Cloud.git

http协议下行不通不妨试一试ssh协议下，就有如下解决方案

# 删除原始origin
git remote remove origin# 使用ssh
git remote add origin git@github.com:Charlesbibi/Simple_Cloud.git# 正常push就没问题了
git push -u origin main

需要注意的是，使用SSH协议首次需要与github进行认证，具体步骤如下：

打开gitbash，并输入：（-C 后面对应的是你自己的邮箱，最好跟github绑定的一致）
 

ssh-keygen -t rsa -C "xxx@example.com" 

会在 .ssh 目录生产两个文件：id_rsa（私有密钥）和id_rsa.pub（公开密钥）

一路默认就行了（回车）如果想自定义更复杂的可以自行研究研究，读取公钥：

cat ~/.ssh/id_rsa.pub

最后将结果复制到 settings - SSH and GPG keys - 左上角New SSH key 中，此时就以及成功完成了，也可以通过命令验证一下：

ssh -T git@github.com

如果出现如下的提示，则说明ssh可以正常连接使用啦！

3. HTTP和SSH的区别

从认证方式而言

• SSH：使用非对称加密，需要生成SSH密钥对，并将公钥上传到GitHub账户中。
• HTTPS：通常通过用户名和密码进行授权，可能更适合那些没有SSH环境的新手用户。

从配置复杂度而言

• SSH：初次设置较为复杂，需要生成和上传SSH密钥，但之后的使用过程中无需重复验证。
• HTTPS：相对简单，不需要额外配置，适合快速开始项目，但每次推送都要输入密码。

从安全性而言

• SSH：提供更高的安全性，因为通信过程是加密的，且不传输密码。
• HTTPS：虽然也是加密的，但在企业防火墙内使用可能会受到限制。

从访问速度而言

• SSH：速度稍慢，因为加密层次更多。
• HTTPS：速度较快，因为通常企业的防火墙会优化80和443端口的通信。

从应用场景而言

• SSH：更适合内部项目或者需要频繁推送的场景。
• HTTPS：适合开源项目或者对外共享的仓库，方便他人克隆和读取。

从兼容性而言

• SSH：在某些严格限制出站连接的企业或学校网络中可能无法使用，因为这些网络可能不允许通过SSH端口(22)进行通信。
• HTTPS：由于使用的是常见的HTTPS端口(443)，通常不会受到这种限制。

这篇关于【已解决】Error in the HTTP2 framing layer的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---