HTTP1.0 HTTP 1.1 HTTP 2.0主要区别
##HTTP1.0 HTTP 1.1主要区别
###长连接
HTTP 1.0需要使用keep-alive参数来告知服务器端要建立一个长连接,而HTTP1.1默认支持长连接。
HTTP是基于TCP/IP协议的,创建一个TCP连接是需要经过三次握手的,有一定的开销,如果每次通讯都要重新建立连接的话,对性能有影响。因此最好能维持一个长连接,可以用个长连接来发多个请求。
###节约带宽
HTTP 1.1支持只发送header信息(不带任何body信息),如果服务器认为客户端有权限请求服务器,则返回100,否则返回401。客户端如果接受到100,才开始把请求body发送到服务器。
这样当服务器返回401的时候,客户端就可以不用发送请求body了,节约了带宽。
另外HTTP还支持传送内容的一部分。这样当客户端已经有一部分的资源后,只需要跟服务器请求另外的部分资源即可。这是支持文件断点续传的基础。
###HOST域
现在可以web server例如tomat,设置虚拟站点是非常常见的,也即是说,web server上的多个虚拟站点可以共享同一个ip和端口。
HTTP1.0是没有host域的,HTTP1.1才支持这个参数。
##HTTP1.1 HTTP 2.0主要区别
###多路复用
HTTP2.0使用了多路复用的技术,做到同一个连接并发处理多个请求,而且并发请求的数量比HTTP1.1大了好几个数量级。
当然HTTP1.1也可以多建立几个TCP连接,来支持处理更多并发的请求,但是创建TCP连接本身也是有开销的。
TCP连接有一个预热和保护的过程,先检查数据是否传送成功,一旦成功过,则慢慢加大传输速度。因此对应瞬时并发的连接,服务器的响应就会变慢。所以最好能使用一个建立好的连接,并且这个连接可以支持瞬时并发的请求。
关于多路复用,可以参看学习NIO 。
###数据压缩
HTTP1.1不支持header数据的压缩,HTTP2.0使用HPACK算法对header的数据进行压缩,这样数据体积小了,在网络上传输就会更快。
##服务器推送
意思是说,当我们对支持HTTP2.0的web server请求数据的时候,服务器会顺便把一些客户端需要的资源一起推送到客户端,免得客户端再次创建连接发送请求到服务器端获取。这种方式非常合适加载静态资源。
服务器端推送的这些资源其实存在客户端的某处地方,客户端直接从本地加载这些资源就可以了,不用走网络,速度自然是快很多的。
参考的文章
1、HTTP/2.0 相比1.0有哪些重大改进?
2、深入研究:HTTP2 的真正性能到底如何
git命令行工作环境配置
##git config 简要介绍
git的配置选项有三种:–system,–global 和 –local
- system是系统级别的全局设置,对所有电脑用户生效,文件在/etc/gitconfig;
- global是个人用户的全局配置,对所有个人用户的代码库生效,文件在$HOME/.config/git/config或者~/.gitconfig;
- local是代码库的设置,仅对设置的代码库生效,文件在代码库的.git/config。
git config常用命令
# 显示全局配置信息
git config --global --list
# 设置全局的用户名和邮箱
git config --global user.name "wellphone"
git config --global user.email wellphone@example.com
# 开启颜色
git config --global color.ui true
更详细的配置见Git-详细配置
##设置别名
git 命令一般较长,如果想少输入几个字可以设置别名,如下:
git config --global alias.st status
git config --global alias.ci commit
git config --global alias.co checkout
git config --global alias.br branch
除此之外,还可以创造自己的命令。比方说取消暂存文件时的输入比较繁琐,可以自己设置一下:
git config --global alias.unstage 'reset HEAD --'
然后,取消暂存文件的时候,只需要输入:
git unstage file
##自定义log显示
默认不用任何参数的话,git log会按提交时间列出所有的更新,最近的更新排在最上面。每次更新都有一个SHA-1校验和、作者的名字和电子邮件地址、提交时间,最后缩进一个段落显示提交说明。但是没有图形化的分支图表来的直接美观。还好,git给我们提供了一个常用的 –pretty选项,可以指定使用完全不同于默认格式的方式展示提交历史。比如用 oneline将每个提交放在一行显示,这在提交数很大时非常有用。另外还有 short,full 和 fuller 可以用,展示的信息完全可以按照自己的喜好来。
比如笔者自己配置的这条命令:
git log --color --graph --pretty=format:'%C(yellow)%h%Creset%C(cyan)%C(bold)%C(red)%d%Creset %s %C(green)[%cn] %Creset%C(cyan)[%cd]%Creset' --date=format-local:'%m-%d %H:%M'
图:
当然,我们可以使用别名的方法来使用这条命令:
git config --global alias.lg "log --color --graph --pretty=format:'%C(yellow)%h%Creset%C(cyan)%C(bold)%C(red)%d%Creset %s %C(green)[%cn] %Creset%C(cyan)[%cd]%Creset' --date=format-local:'%m-%d %H:%M'"
输入上条命令后,以后只需要输入git lg就可以看到自定义显示的log。
更多关于log配置信息可以查看Git-基础-查看提交历史
##设置自动补全命令
git 命令没有自动补全功能,这个在命令行下让人非常抓狂,尤其是在各个分支间切换的时候,狂按tab键也不能补全分支的名字。还好,有git的资深开发为我等小白准备好了自动补全功能。
如果用的是Bash shell,到git的官方源码库中的git/contrib/compleion
文件夹git compleiton下载git-completion.bash文件。 将该文件复制到你自己的用户主目录中(译注:按照下面的示例,还应改名加上点:cp git-completion.bash ~/.git-completion.bash),并把下面一行内容添加到你的 .bashrc 文件中:
source ~/.git-completion.bash
在输入 Git 命令的时候可以敲两次跳格键(Tab),就会看到列出所有匹配的可用命令建议。
如图:
##设置命令prompt提示
我们在使用sourceTree的时候可以很方便看见当前工作的分支,work区,stage区的修改情况。但是在命令行下,我们需要执行git status才能知道这些信息,显得不是很方便。这个情况也有资深开发替我们解决了。我们只需要简单配置下就能在命令行的prompt提示中看见当前分支及修改情况。
同样的我们需要在git官方代码库中下载git-prompt.sh文件。
- 将下载下来的文件复制到~目录下。(e.g. ~/.git-prompt.sh)
- 将以下命令加入到~/.bash_profile或者是~/.bashrc文件里
source ~/.git-prompt.sh
- 修改自己的环境变量中的PS1值,PROMPT_COMMAND值
export PS1='[u@h W$(__git_ps1 " (%s)")]$ '
export PROMPT_COMMAND='__git_ps1 "u@h:W" "\$ "'
这时,在命令行提示符上已经可以显示当前的分支名了。
设置如下环境变量值
export GIT_PS1_SHOWDIRTYSTATE=true
export GIT_PS1_SHOWCOLORHINTS=true
export GIT_PS1_SHOWUNTRACKEDFILES=true
export GIT_PS1_SHOWUPSTREAM="auto"
如果设置GIT_PS1_SHOWDIRTYSTATE为非空值,则会使用(*)表示有文件未放入暂存区(unstaged files),(+)表示暂存区有文件(staged files)。
如果设置GIT_PS1_SHOWUNTRACKEDFILES为非空值,则会使用(%)表示有没有加入到git中的文件(untracked files)。
如果设置GIT_PS1_SHOWCOLORHINTS为非空值,则会显示颜色。 如果设置GIT_PS1_SHOWUPSTREAM=“auto”,则会使用(<)表示当前节点落后远程分支,(>)表示远程分支节点落后当前分支,(=)表示当前分支和远程分支一样,(<>)表示当前分支同远程分支分叉了。 如图:
##总结
以上只是笔者在日常工作中碰见的一些简单git配置方法,如果大家有更好更高效率的git命令使用方法,欢迎留言分享~~~ 附:git使用手册
[阿里云ECS]GitLab的安装及使用
##前言
GitLab是利用 Ruby on Rails 一个开源的版本管理系统,实现一个自托管的Git项目仓库,可通过Web界面进行访问公开的或者私人项目。
它拥有与Github类似的功能,能够浏览源代码,管理缺陷和注释。可以管理团队对仓库的访问,它非常易于浏览提交过的版本并提供一个文件历史库。
团队成员可以利用内置的简单聊天程序(Wall)进行交流。
它还提供一个代码片段收集功能可以轻松实现代码复用,便于日后有需要的时候进行查找。
###Git的家族成员
Git:是一种版本控制系统,是一个命令,是一种工具。
Gitlib:是用于实现Git功能的开发库。
Github:是一个基于Git实现的在线代码托管仓库,包含一个网站界面,向互联网开放。
GitLab:是一个基于Git实现的在线代码仓库托管软件,你可以用gitlab自己搭建一个类似于Github一样的系统,一般用于在企业、学校等内部网络搭建git私服。
###Gitlab的服务构成
Nginx:静态web服务器。
gitlab-shell:用于处理Git命令和修改authorized keys列表。
gitlab-workhorse:轻量级的反向代理服务器。
logrotate:日志文件管理工具。
postgresql:数据库。
redis:缓存数据库。
sidekiq:用于在后台执行队列任务(异步执行)。
unicorn:An HTTP server for Rack applications,GitLab Rails应用是托管在这个服务器上面的。
###GitLab工作流程
###GitLab Shell
GitLab Shell有两个作用:为GitLab处理Git命令、修改authorized keys列表。
当通过SSH访问GitLab Server时,GitLab Shell会:
限制执行预定义好的Git命令(git push, git pull, git annex)
调用GitLab Rails API 检查权限
执行pre-receive钩子(在GitLab企业版中叫做Git钩子)
执行你请求的动作 处理GitLab的post-receive动作
处理自定义的post-receive动作
当通过http(s)访问GitLab Server时,工作流程取决于你是从Git仓库拉取(pull)代码还是向git仓库推送(push)代码。
如果你是从Git仓库拉取(pull)代码,GitLab Rails应用会全权负责处理用户鉴权和执行Git命令的工作;
如果你是向Git仓库推送(push)代码,GitLab Rails应用既不会进行用户鉴权也不会执行Git命令,它会把以下工作交由GitLab Shell进行处理:
- 调用GitLab Rails API 检查权限
- 执行pre-receive钩子(在GitLab企业版中叫做Git钩子)
- 执行你请求的动作
- 处理GitLab的post-receive动作
- 处理自定义的post-receive动作
###GitLab Workhorse
GitLab Workhorse是一个敏捷的反向代理。它会处理一些大的HTTP请求,比如文件上传、文件下载、Git push/pull和Git包下载。其它请求会反向代理到GitLab Rails应用,即反向代理给后端的unicorn
##Gitlab环境部署
ECS配置要求:内存2G以上
方法一:镜像部署
镜像名称:GitLab代码管理(Centos 64位 | GitLab) | 镜像帮助文档
进入镜像详情页面,单击立即购买,按提示步骤购买 ECS 实例。
购买完成之后,登录”ECS 管理控制台”,在左边导航栏里,单击”实例”,进入 ECS 实例列表页,选择所购 ECS 实例所在的地域,并找到所购 ECS 实例,在”IP 地址”列获取该实例的公网 IP 地址。
注意:镜像部署好后默认是禁止远端访问的,所以直接访问ECS服务器的公网IP是不能访问到GitLab的登录界面的,请先运行/alidata目录下的gitlab_opennet.sh脚本,开启远程访问,然后再通过浏览器访问公网IP来访问GitLab的主页。
方法二:手动部署:
1、配置yum源
vim /etc/yum.repos.d/gitlab-ce.repo
复制以下内容:
[gitlab-ce]
name=gitlab-ce
baseurl=http://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7
Repo_gpgcheck=0
Enabled=1
Gpgkey=https://packages.gitlab.com/gitlab/gitlab-ce/gpgkey
https://packages.gitlab.com/gitlab/gitlab-ce/gpgkey/gitlab-gitlab-ce-3D645A26AB9FBD22.pub.gpg
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300
2、更新本地yum缓存
sudo yum makecache
3、安装GitLab社区版
sudo yum install gitlab-ce #自动安装最新版
//sudo yum install gitlab-ce-x.x.x #安装指定版本
GitLab常用命令:
sudo gitlab-ctl start # 启动所有 gitlab 组件;
sudo gitlab-ctl stop # 停止所有 gitlab 组件;
sudo gitlab-ctl restart # 重启所有 gitlab 组件;
sudo gitlab-ctl status # 查看服务状态;
sudo gitlab-ctl reconfigure # 启动服务;
sudo vim /etc/gitlab/gitlab.rb # 修改默认的配置文件;
gitlab-rake gitlab:check SANITIZE=true --trace # 检查gitlab;
sudo gitlab-ctl tail # 查看日志;
4、修改配置文件
#修改url,供外部访问
[root@gitlab ~]# vi /etc/gitlab/gitlab.rb
external_url'http://gitlab.server.com'
external_url 修改成自己的ip或者域名
#修改配置文件之后,需要重新是配置文件生效下,初始化下
[root@gitlab ~]#gitlab-ctl reconfigure #这里会花费一定的时间(1-10min),如果这里内存小,将会花费大量时间
Recipe: gitlab::gitlab-rails
*execute[clear the gitlab-rails cache] action run
-execute /opt/gitlab/bin/gitlab-rake cache:clear
*execute[clear the gitlab-rails cache] action run
-execute /opt/gitlab/bin/gitlab-rake cache:clear
Recipe: gitlab::unicorn
*service[unicorn] action restart
-restart service service[unicorn]
Recipe: gitlab::redis
*ruby_block[reload redis svlogd configuration] action create
-execute the ruby block reload redis svlogd configuration
Recipe: gitlab::postgresql
*ruby_block[reload postgresql svlogd configuration] action create
-execute the ruby block reload postgresql svlogd configuration
Recipe: gitlab::unicorn
*ruby_block[reload unicorn svlogd configuration] action create
-execute the ruby block reload unicorn svlogd configuration
Recipe: gitlab::sidekiq
*ruby_block[reload sidekiq svlogd configuration] action create
-execute the ruby block reload sidekiq svlogd configuration
Recipe: gitlab::gitlab-workhorse
*service[gitlab-workhorse] action restart
-restart service service[gitlab-workhorse]
*ruby_block[reload gitlab-workhorse svlogd configuration] action create
-execute the ruby block reload gitlab-workhorse svlogd configuration
Recipe: gitlab::gitlab-workhorse
*service[gitlab-workhorse] action restart
-restart service service[gitlab-workhorse]
*ruby_block[reload gitlab-workhorse svlogd configuration] action create
-execute the ruby block reload gitlab-workhorse svlogd configuration
Recipe: gitlab::nginx
*ruby_block[reload nginx svlogd configuration] action create
-execute the ruby block reload nginx svlogd configuration
Recipe: gitlab::logrotate
*ruby_block[reload logrotate svlogd configuration] action create
-execute the ruby block reload logrotate svlogd configuration
Running handlers:
Running handlers complete
Chef Client finished, 222/309 resources updatedin 02 minutes 50 seconds
`该过程还要进行域名解析或者IP指定`
5、启动Gitlab服务
[root@gitlab ~]# gitlab-ctl start
ok: down:gitaly: 0s, normally up
ok: down:gitlab-monitor: 1s, normally up
ok: down: gitlab-workhorse: 0s, normally up
ok: down: logrotate: 0s, normally up
ok: down: nginx: 0s, normally up
ok: down:node-exporter: 0s, normally up
ok: down:postgres-exporter: 1s, normally up
ok: down: postgresql: 0s, normally up
ok: down:prometheus: 1s, normally up
ok: down: redis: 0s, normally up
ok: down:redis-exporter: 0s, normally up
ok: down: sidekiq: 0s, normally up
ok: down: unicorn: 1s, normally up
注解:
绿色部分是9中新添加的
ü gitlab-workhorse这个“工作马”,就是gitlab-Git-http-server(GitlabV8.0出现,V8.2名称变更为Gitlab-workhorse)
ü sidekiq多线程启动
ü unicorn是ruby的http server,可以通过http://localhost:8080端口访问, 默认端口是8080
ü nginx作为方向代理,代理到unicorn,nginx默认端口是80
ü postgresql作为数据库,默认端口是5432
ü redis作为一个队列(NoSql),用于存储用户session和任务,任务包括新建仓库、发送邮件等等,默认端口是6379
ü logrotate切割日志
ü prometheus监控,默认端口9090
ü gitlab-monitor默认端口9168
注:
(可选)如果系统资源不足,可以通过以下命令关闭Sidekiq来释放一部分内存
[root@gitlab ~]# gitlab-ctl stop sidekiq
ok: down: sidekiq: 0s, normally up
参考:
https://packages.gitlab.com/gitlab/gitlab-ce/install#manual
Copyright © 2015 Powered by MWeb, 豫ICP备09002885号-5