git init 建立git倉庫
git status 查看當前狀態
git add <file> 添加文件到緩衝區
git commit -m 「…」提交
git diff <file> 對比文件
git log 命令顯示從近到遠的提交日誌
git log –pretty=online 格式化javascript
版本退回
HEAD 表示當前版本
HEAD^ 表示上一個版本
HEAD^^ 表示上上個版本
git reset –hard HEAD^
git reset –hard 1111111 退回到指定的版本 1111111表示commit id
git reflog 顯示命令執行歷史
git checkout –<file> 撤銷工做區的修改。
git reset HEAD file 撤銷已經add的修改。php
刪除文件
rm <file> 從本地刪除文件
git -rm <file> 刪除版本庫中的文件css
遠程倉庫
關聯遠程倉庫 git默認爲origin
git remote add origin git@github.com:zongyl/learngit.git
把當前分支master推送到遠程。第一次推送遠程，加上-u參數，能夠將本地的master 和遠程的master分支關聯起來。
之後的推送或者拉去能夠簡化命令。
git push -u origin master
git push origin master 提交到遠程。
從遠程克隆到本地
git clone git@github.com:zongyl/learngit.git
git支持多種協議，默認的git://使用shh，但也能夠用https等其餘協議。 git協議速度最快。html
分支管理
git checkout -b dev –建立並切換到dev分支上
-b 表示建立並切換，至關於如下兩條命令
git branch dev
git checkout dev
git branch —列出全部分支，帶*號的爲當前分支
git merge dev —合併指定分支(dev)到當前分支。
git branch -d dev —刪除分支
git log –graph —查看分支合併圖。
分支合併時，git默認使用fast forward模式。刪除分支後，會丟掉分支信息，看不出作過合併。
git merge –no–ff dev 合併分支，禁用fast forward 模式。前端
本條目發佈於
2014年11月16日。屬於
未分類分類。
#定義Nginx運行的用戶和用戶組
user www;java
#nginx進程數，建議設置爲等於CPU總核心數。
worker_processes 4;node
#全局錯誤日誌定義類型，[ debug | info | notice | warn | error | crit ]
error_log logs/error.log info;linux
#進程文件
pid logs/nginx.pid;nginx
#一個nginx進程打開的最多文件描述符數目，理論值應該是最多打開文件數（系統的值ulimit -n）與nginx進程數相除，可是nginx分配請求並不均勻，因此建議與ulimit -n的值保持一致。
worker_rlimit_nofile 65535;git
#工做模式與鏈接數上限
events
{
#參考事件模型，use [ kqueue | rtsig | epoll | /dev/poll | select | poll ]; epoll模型是Linux 2.6以上版本內核中的高性能網絡I/O模型，若是跑在FreeBSD上面，就用kqueue模型。
use epoll;
#單個進程最大鏈接數（最大鏈接數=鏈接數*進程數）
worker_connections 65535;
}
#設定http服務器
http
{
include mime.types; #文件擴展名與文件類型映射表
default_type application/octet-stream; #默認文件類型
#charset utf-8; #默認編碼
server_names_hash_bucket_size 128; #服務器名字的hash表大小
client_header_buffer_size 32k; #上傳文件大小限制
large_client_header_buffers 4 64k; #設定請求緩
client_max_body_size 8m; #設定請求緩
sendfile on; #開啓高效文件傳輸模式，sendfile指令指定nginx是否調用sendfile函數來輸出文件，對於普通應用設爲 on，若是用來進行下載等應用磁盤IO重負載應用，可設置爲off，以平衡磁盤與網絡I/O處理速度，下降系統的負載。注意：若是圖片顯示不正常把這個改 成off。
autoindex on; #開啓目錄列表訪問，合適下載服務器，默認關閉。
tcp_nopush on; #防止網絡阻塞
tcp_nodelay on; #防止網絡阻塞
keepalive_timeout 120; #長鏈接超時時間，單位是秒
#FastCGI相關參數是爲了改善網站的性能：減小資源佔用，提升訪問速度。下面參數看字面意思都能理解。
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 128k;
#gzip模塊設置
gzip on; #開啓gzip壓縮輸出
gzip_min_length 1k; #最小壓縮文件大小
gzip_buffers 4 16k; #壓縮緩衝區
gzip_http_version 1.0; #壓縮版本（默認1.1，前端若是是squid2.5請使用1.0）
gzip_comp_level 2; #壓縮等級
gzip_types text/plain application/x-javascript text/css application/xml;
#壓縮類型，默認就已經包含textml，因此下面就不用再寫了，寫上去也不會有問題，可是會有一個warn。
gzip_vary on;
#limit_zone crawler $binary_remote_addr 10m; #開啓限制IP鏈接數的時候須要使用
upstream myservers {
#upstream的負載均衡，weight是權重，能夠根據機器配置定義權重。weigth參數表示權值，權值越高被分配到的概率越大。
server 192.168.0.121:80 weight=3;
server 192.168.0.122:80 weight=2;
server 192.168.0.123:80 weight=3;
}
#虛擬主機的配置
server
{
#監聽端口
listen 80;
#域名能夠有多個，用空格隔開
server_name www.52huikou.com 52huikou.com;
index index.html index.htm index.php;
root /data/www/52huikou;
location ~ .*.(php|php5)?$
{
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi.conf;
}
#圖片緩存時間設置
location ~ .*.(gif|jpg|jpeg|png|bmp|swf)$
{
expires 10d;
}
#JS和CSS緩存時間設置
location ~ .*.(js|css)?$
{
expires 1h;
}
#日誌格式設定
log_format access ‘$remote_addr – $remote_user [$time_local] 「$request」 ‘
‘$status $body_bytes_sent 「$http_referer」 ‘
‘」$http_user_agent」 $http_x_forwarded_for';
#定義本虛擬主機的訪問日誌
access_log logs/access.log access;
#對 「/」 啓用反向代理
location / {
proxy_pass http://127.0.0.1:88;
proxy_redirect off;
proxy_set_header X-Real-IP $remote_addr;
#後端的Web服務器能夠經過X-Forwarded-For獲取用戶真實IP
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
#如下是一些反向代理的配置，可選。
proxy_set_header Host $host;
client_max_body_size 10m; #容許客戶端請求的最大單文件字節數
client_body_buffer_size 128k; #緩衝區代理緩衝用戶端請求的最大字節數，
proxy_connect_timeout 90; #nginx跟後端服務器鏈接超時時間(代理鏈接超時)
proxy_send_timeout 90; #後端服務器數據回傳時間(代理髮送超時)
proxy_read_timeout 90; #鏈接成功後，後端服務器響應時間(代理接收超時)
proxy_buffer_size 4k; #設置代理服務器（nginx）保存用戶頭信息的緩衝區大小
proxy_buffers 4 32k; #proxy_buffers緩衝區，網頁平均在32k如下的設置
proxy_busy_buffers_size 64k; #高負荷下緩衝大小（proxy_buffers*2）
proxy_temp_file_write_size 64k;
#設定緩存文件夾大小，大於這個值，將從upstream服務器傳
}
#設定查看Nginx狀態的地址
location /NginxStatus {
stub_status on;
access_log on;
auth_basic 「NginxStatus」;
auth_basic_user_file confpasswd;
#htpasswd文件的內容能夠用apache提供的htpasswd工具來產生。
}
#本地動靜分離反向代理配置
#全部jsp的頁面均交由tomcat或resin處理
location ~ .(jsp|jspx|do)?$ {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://127.0.0.1:8080;
}
#全部靜態文件由nginx直接讀取不通過tomcat或resin
location ~ .*.(htm|html|gif|jpg|jpeg|png|bmp|swf|ioc|rar|zip|txt|flv|mid|doc|ppt|pdf|xls|mp3|wma)$
{ expires 15d; }
location ~ .*.(js|css)?$
{ expires 1h; }
}
}
更多詳細內容請參考 http://wiki.nginx.org/Main
本條目發佈於
2014年11月13日。屬於
未分類分類。
引言
HTTP是一個屬於應用層的面向對象的協議，因爲其簡捷、快速的方式，適用於分佈式超媒體信息系統。它於1990年提出，通過幾年的使用與發展，獲得不斷 地完善和擴展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規範化工做正在進行之中，並且HTTP-NG(Next Generation of HTTP)的建議已經提出。
HTTP協議的主要特色可歸納以下：
1.支持客戶/服務器模式。
2.簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。
3.靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
4.無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。
5.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。
1、HTTP協議詳解之URL篇
http（超文本傳輸協議）是一個基於請求與響應模式的、無狀態的、應用層的協議，常基於TCP的鏈接方式，HTTP1.1版本中給出一種持續鏈接的機制，絕大多數的Web開發，都是構建在HTTP協議之上的Web應用。
HTTP URL (URL是一種特殊類型的URI，包含了用於查找某個資源的足夠的信息)的格式以下：
http://host[「:」port][abs_path]
http表示要經過HTTP協議來定位網絡資源；host表示合法的Internet主機域名或者IP地址；port指定一個端口號，爲空則使用缺省端口 80；abs_path指定請求資源的URI；若是URL中沒有給出abs_path，那麼當它做爲請求URI時，必須以「/」的形式給出，一般這個工做 瀏覽器自動幫咱們完成。
eg:
一、輸入：www.guet.edu.cn
瀏覽器自動轉換成：http://www.guet.edu.cn/
二、http:192.168.0.116:8080/index.jsp
2、HTTP協議詳解之請求篇
http請求由三部分組成，分別是：請求行、消息報頭、請求正文
一、請求行以一個方法符號開頭，以空格分開，後面跟着請求的URI和協議的版本，格式以下：Method Request-URI HTTP-Version CRLF
其中 Method表示請求方法；Request-URI是一個統一資源標識符；HTTP-Version表示請求的HTTP協議版本；CRLF表示回車和換行（除了做爲結尾的CRLF外，不容許出現單獨的CR或LF字符）。
請求方法（全部方法全爲大寫）有多種，各個方法的解釋以下：
GET 請求獲取Request-URI所標識的資源
POST 在Request-URI所標識的資源後附加新的數據
HEAD 請求獲取由Request-URI所標識的資源的響應消息報頭
PUT 請求服務器存儲一個資源，並用Request-URI做爲其標識
DELETE 請求服務器刪除Request-URI所標識的資源
TRACE 請求服務器回送收到的請求信息，主要用於測試或診斷
CONNECT 保留未來使用
OPTIONS 請求查詢服務器的性能，或者查詢與資源相關的選項和需求
應用舉例：
GET方法：在瀏覽器的地址欄中輸入網址的方式訪問網頁時，瀏覽器採用GET方法向服務器獲取資源，eg:GET /form.html HTTP/1.1 (CRLF)
POST方法要求被請求服務器接受附在請求後面的數據，經常使用於提交表單。
eg：POST /reg.jsp HTTP/ (CRLF)
Accept:image/gif,image/x-xbit,… (CRLF)
…
HOST:www.guet.edu.cn (CRLF)
Content-Length:22 (CRLF)
Connection:Keep-Alive (CRLF)
Cache-Control:no-cache (CRLF)
(CRLF) //該CRLF表示消息報頭已經結束，在此以前爲消息報頭
user=jeffrey&pwd=1234 //此行如下爲提交的數據
HEAD方法與GET方法幾乎是同樣的，對於HEAD請求的迴應部分來講，它的HTTP頭部中包含的信息與經過GET請求所獲得的信息是相同的。利 用這個方法，沒必要傳輸整個資源內容，就能夠獲得Request-URI所標識的資源的信息。該方法經常使用於測試超連接的有效性，是否能夠訪問，以及最近是否 更新。
二、請求報頭後述
三、請求正文(略)
3、HTTP協議詳解之響應篇
在接收和解釋請求消息後，服務器返回一個HTTP響應消息。
HTTP響應也是由三個部分組成，分別是：狀態行、消息報頭、響應正文
一、狀態行格式以下：
HTTP-Version Status-Code Reason-Phrase CRLF
其中，HTTP-Version表示服務器HTTP協議的版本；Status-Code表示服務器發回的響應狀態代碼；Reason-Phrase表示狀態代碼的文本描述。
狀態代碼有三位數字組成，第一個數字定義了響應的類別，且有五種可能取值：
1xx：指示信息–表示請求已接收，繼續處理
2xx：成功–表示請求已被成功接收、理解、接受
3xx：重定向–要完成請求必須進行更進一步的操做
4xx：客戶端錯誤–請求有語法錯誤或請求沒法實現
5xx：服務器端錯誤–服務器未能實現合法的請求
常見狀態代碼、狀態描述、說明：
200 OK //客戶端請求成功
400 Bad Request //客戶端請求有語法錯誤，不能被服務器所理解
401 Unauthorized //請求未經受權，這個狀態代碼必須和WWW-Authenticate報 //頭域一塊兒使用
403 Forbidden //服務器收到請求，可是拒絕提供服務
404 Not Found //請求資源不存在，eg：輸入了錯誤的URL
500 Internal Server Error //服務器發生不可預期的錯誤
503 Server Unavailable //服務器當前不能處理客戶端的請求，一段時間後， //可能恢復正常
eg：HTTP/1.1 200 OK （CRLF）
二、響應報頭後述
三、響應正文就是服務器返回的資源的內容
4、HTTP協議詳解之消息報頭篇
HTTP消息由客戶端到服務器的請求和服務器到客戶端的響應組成。請求消息和響應消息都是由開始行（對於請求消息，開始行就是請求行，對於響應消息，開始行就是狀態行），消息報頭（可選），空行（只有CRLF的行），消息正文（可選）組成。
HTTP消息報頭包括普通報頭、請求報頭、響應報頭、實體報頭。
每個報頭域都是由名字+「：」+空格+值 組成，消息報頭域的名字是大小寫無關的。
一、普通報頭
在普通報頭中，有少數報頭域用於全部的請求和響應消息，但並不用於被傳輸的實體，只用於傳輸的消息。
eg：
Cache-Control 用於指定緩存指令，緩存指令是單向的（響應中出現的緩存指令在請求中未必會出現），且是獨立的（一個消息的緩存指令不會影響另外一個消息處理的緩存機制），HTTP1.0使用的相似的報頭域爲Pragma。
請求時的緩存指令包括：no-cache（用於指示請求或響應消息不能緩存）、no-store、max-age、max-stale、min-fresh、only-if-cached;
響應時的緩存指令包括：public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage.
eg：爲了指示IE瀏覽器（客戶端）不要緩存頁面，服務器端的JSP程序能夠編寫以下：response.sehHeader(「Cache-Control」,」no-cache」);
//response.setHeader(「Pragma」,」no-cache」);做用至關於上述代碼，一般二者//合用
這句代碼將在發送的響應消息中設置普通報頭域：Cache-Control:no-cache
Date普通報頭域表示消息產生的日期和時間
Connection普通報頭域容許發送指定鏈接的選項。例如指定鏈接是連續，或者指定「close」選項，通知服務器，在響應完成後，關閉鏈接
二、請求報頭
請求報頭容許客戶端向服務器端傳遞請求的附加信息以及客戶端自身的信息。
經常使用的請求報頭
Accept
Accept請求報頭域用於指定客戶端接受哪些類型的信息。eg：Accept：image/gif，代表客戶端但願接受GIF圖象格式的資源；Accept：text/html，代表客戶端但願接受html文本。
Accept-Charset
Accept-Charset請求報頭域用於指定客戶端接受的字符集。eg：Accept-Charset:iso-8859-1,gb2312.若是在請求消息中沒有設置這個域，缺省是任何字符集均可以接受。
Accept-Encoding
Accept-Encoding請求報頭域相似於Accept，可是它是用於指定可接受的內容編碼。eg：Accept-Encoding:gzip.deflate.若是請求消息中沒有設置這個域服務器假定客戶端對各類內容編碼均可以接受。
Accept-Language
Accept-Language請求報頭域相似於Accept，可是它是用於指定一種天然語言。eg：Accept-Language:zh-cn.若是請求消息中沒有設置這個報頭域，服務器假定客戶端對各類語言均可以接受。
Authorization
Authorization請求報頭域主要用於證實客戶端有權查看某個資源。當瀏覽器訪問一個頁面時，若是收到服務器的響應代碼爲401（未受權），能夠發送一個包含Authorization請求報頭域的請求，要求服務器對其進行驗證。
Host（發送請求時，該報頭域是必需的）
Host請求報頭域主要用於指定被請求資源的Internet主機和端口號，它一般從HTTP URL中提取出來的，eg：
咱們在瀏覽器中輸入：http://www.guet.edu.cn/index.html
瀏覽器發送的請求消息中，就會包含Host請求報頭域，以下：
Host：www.guet.edu.cn
此處使用缺省端口號80，若指定了端口號，則變成：Host：www.guet.edu.cn:指定端口號
User-Agent
咱們上網登錄論壇的時候，每每會看到一些歡迎信息，其中列出了你的操做系統的名稱和版本，你所使用的瀏覽器的名稱和版本，這每每讓不少人感到很神奇，實際 上，服務器應用程序就是從User-Agent這個請求報頭域中獲取到這些信息。User-Agent請求報頭域容許客戶端將它的操做系統、瀏覽器和其它 屬性告訴服務器。不過，這個報頭域不是必需的，若是咱們本身編寫一個瀏覽器，不使用User-Agent請求報頭域，那麼服務器端就沒法得知咱們的信息 了。
請求報頭舉例：
GET /form.html HTTP/1.1 (CRLF)
Accept:image/gif,image/x-xbitmap,image/jpeg,application/x-shockwave-flash,application/vnd.ms-excel,application/vnd.ms-powerpoint,application/msword,*/* (CRLF)
Accept-Language:zh-cn (CRLF)
Accept-Encoding:gzip,deflate (CRLF)
If-Modified-Since:Wed,05 Jan 2007 11:21:25 GMT (CRLF)
If-None-Match:W/」80b1a4c018f3c41:8317″ (CRLF)
User-Agent:Mozilla/4.0(compatible;MSIE6.0;Windows NT 5.0) (CRLF)
Host:www.guet.edu.cn (CRLF)
Connection:Keep-Alive (CRLF)
(CRLF)
三、響應報頭
響應報頭容許服務器傳遞不能放在狀態行中的附加響應信息，以及關於服務器的信息和對Request-URI所標識的資源進行下一步訪問的信息。
經常使用的響應報頭
Location
Location響應報頭域用於重定向接受者到一個新的位置。Location響應報頭域經常使用在更換域名的時候。
Server
Server響應報頭域包含了服務器用來處理請求的軟件信息。與User-Agent請求報頭域是相對應的。下面是
Server響應報頭域的一個例子：
Server：Apache-Coyote/1.1
WWW-Authenticate
WWW-Authenticate響應報頭域必須被包含在401（未受權的）響應消息中，客戶端收到401響應消息時候，併發送Authorization報頭域請求服務器對其進行驗證時，服務端響應報頭就包含該報頭域。
eg：WWW-Authenticate:Basic realm=」Basic Auth Test!」 //能夠看出服務器對請求資源採用的是基本驗證機制。
四、實體報頭
請求和響應消息均可以傳送一個實體。一個實體由實體報頭域和實體正文組成，但並非說實體報頭域和實體正文要在一塊兒發送，能夠只發送實體報頭域。實體報頭定義了關於實體正文（eg：有無實體正文）和請求所標識的資源的元信息。
經常使用的實體報頭
Content-Encoding
Content-Encoding實體報頭域被用做媒體類型的修飾符，它的值指示了已經被應用到實體正文的附加內容的編碼，於是要得到Content- Type報頭域中所引用的媒體類型，必須採用相應的解碼機制。Content-Encoding這樣用於記錄文檔的壓縮方法，eg：Content- Encoding：gzip
Content-Language
Content-Language實體報頭域描述了資源所用的天然語言。沒有設置該域則認爲實體內容將提供給全部的語言閱讀
者。eg：Content-Language:da
Content-Length
Content-Length實體報頭域用於指明實體正文的長度，以字節方式存儲的十進制數字來表示。
Content-Type
Content-Type實體報頭域用語指明發送給接收者的實體正文的媒體類型。eg：
Content-Type:text/html;charset=ISO-8859-1
Content-Type:text/html;charset=GB2312
Last-Modified
Last-Modified實體報頭域用於指示資源的最後修改日期和時間。
Expires
Expires實體報頭域給出響應過時的日期和時間。爲了讓代理服務器或瀏覽器在一段時間之後更新緩存中(再次訪問曾訪問過的頁面時，直接從緩存中加載， 縮短響應時間和下降服務器負載)的頁面，咱們可使用Expires實體報頭域指定頁面過時的時間。eg：Expires：Thu，15 Sep 2006 16:23:12 GMT
HTTP1.1的客戶端和緩存必須將其餘非法的日期格式（包括0）看做已通過期。eg：爲了讓瀏覽器不要緩存頁面，咱們也能夠利用Expires實體報頭域，設置爲0，jsp中程序以下：response.setDateHeader(「Expires」,」0″);
5、利用telnet觀察http協議的通信過程
實驗目的及原理：
利用MS的telnet工具，經過手動輸入http請求信息的方式，向服務器發出請求，服務器接收、解釋和接受請求後，會返回一個響應，該響應會在telnet窗口上顯示出來，從而從感性上加深對http協議的通信過程的認識。
實驗步驟：
一、打開telnet
1.1 打開telnet
運行–>cmd–>telnet
1.2 打開telnet回顯功能
set localecho
二、鏈接服務器併發送請求
2.1 open www.guet.edu.cn 80 //注意端口號不能省略
HEAD /index.asp HTTP/1.0
Host:www.guet.edu.cn
/*咱們能夠變換請求方法,請求桂林電子主頁內容,輸入消息以下*/
open www.guet.edu.cn 80
GET /index.asp HTTP/1.0 //請求資源的內容
Host:www.guet.edu.cn
2.2 open www.sina.com.cn 80 //在命令提示符號下直接輸入telnet www.sina.com.cn 80
HEAD /index.asp HTTP/1.0
Host:www.sina.com.cn
3 實驗結果：
3.1 請求信息2.1獲得的響應是:
HTTP/1.1 200 OK //請求成功
Server: Microsoft-IIS/5.0 //web服務器
Date: Thu,08 Mar 200707:17:51 GMT
Connection: Keep-Alive
Content-Length: 23330
Content-Type: text/html
Expries: Thu,08 Mar 2007 07:16:51 GMT
Set-Cookie: ASPSESSIONIDQAQBQQQB=BEJCDGKADEDJKLKKAJEOIMMH; path=/
Cache-control: private
//資源內容省略
3.2 請求信息2.2獲得的響應是:
HTTP/1.0 404 Not Found //請求失敗
Date: Thu, 08 Mar 2007 07:50:50 GMT
Server: Apache/2.0.54
Last-Modified: Thu, 30 Nov 2006 11:35:41 GMT
ETag: 「6277a-415-e7c76980″
Accept-Ranges: bytes
X-Powered-By: mod_xlayout_jh/0.0.1vhs.markII.remix
Vary: Accept-Encoding
Content-Type: text/html
X-Cache: MISS from zjm152-78.sina.com.cn
Via: 1.0 zjm152-78.sina.com.cn:80<squid/2.6.STABLES-20061207>
X-Cache: MISS from th-143.sina.com.cn
Connection: close
失去了跟主機的鏈接
按任意鍵繼續…
4 .注意事項：一、出現輸入錯誤，則請求不會成功。
二、報頭域不分大小寫。
三、更深一步瞭解HTTP協議，能夠查看RFC2616，在http://www.letf.org/rfc上找到該文件。
四、開發後臺程序必須掌握http協議
6、HTTP協議相關技術補充
一、基礎：
高層協議有：文件傳輸協議FTP、電子郵件傳輸協議SMTP、域名系統服務DNS、網絡新聞傳輸協議NNTP和HTTP協議等
中介由三種：代理(Proxy)、網關(Gateway)和通道(Tunnel)，一個代理根據URI的絕對格式來接受請求，重寫所有或部分消息，經過 URI的標識把已格式化過的請求發送到服務器。網關是一個接收代理，做爲一些其它服務器的上層，而且若是必須的話，能夠把請求翻譯給下層的服務器協議。一 個通道做爲不改變消息的兩個鏈接之間的中繼點。當通信須要經過一箇中介(例如：防火牆等)或者是中介不能識別消息的內容時，通道常常被使用。
代理(Proxy)：一箇中間程序，它能夠充當一個服務器，也能夠充當一個客戶機，爲其它客戶機創建請求。請求是經過可能的翻譯在內部或通過傳遞到其它的 服務器中。一個代理在發送請求信息以前，必須解釋而且若是可能重寫它。代理常常做爲經過防火牆的客戶機端的門戶，代理還能夠做爲一個幫助應用來經過協議處 理沒有被用戶代理完成的請求。
網關(Gateway)：一個做爲其它服務器中間媒介的服務器。與代理不一樣的是，網關接受請求就好象對被請求的資源來講它就是源服務器；發出請求的客戶機並無意識到它在同網關打交道。
網關常常做爲經過防火牆的服務器端的門戶，網關還能夠做爲一個協議翻譯器以便存取那些存儲在非HTTP系統中的資源。
通道(Tunnel)：是做爲兩個鏈接中繼的中介程序。一旦激活，通道便被認爲不屬於HTTP通信，儘管通道多是被一個HTTP請求初始化的。當被中繼 的鏈接兩端關閉時，通道便消失。當一個門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通信時通道被常用。
二、協議分析的優點—HTTP分析器檢測網絡攻擊
以模塊化的方式對高層協議進行分析處理，將是將來入侵檢測的方向。
HTTP及其代理的經常使用端口80、3128和8080在network部分用port標籤進行了規定
三、HTTP協議Content Lenth限制漏洞致使拒絕服務攻擊
使用POST方法時，能夠設置ContentLenth來定義須要傳送的數據長度，例如ContentLenth:999999999，在傳送完成前，內 存不會釋放，攻擊者能夠利用這個缺陷，連續向WEB服務器發送垃圾數據直至WEB服務器內存耗盡。這種攻擊方法基本不會留下痕跡。
http://www.cnpaf.net/Class/HTTP/0532918532667330.html
四、利用HTTP協議的特性進行拒絕服務攻擊的一些構思
服務器端忙於處理攻擊者僞造的TCP鏈接請求而無暇理睬客戶的正常請求（畢竟客戶端的正常請求比率很是之小），此時從正常客戶的角度看來，服務器失去響應，這種狀況咱們稱做：服務器端受到了SYNFlood攻擊（SYN洪水攻擊）。
而Smurf、TearDrop等是利用ICMP報文來Flood和IP碎片攻擊的。本文用「正常鏈接」的方法來產生拒絕服務攻擊。
19端口在早期已經有人用來作Chargen攻擊了，即Chargen_Denial_of_Service，可是！他們用的方法是在兩臺Chargen 服務器之間產生UDP鏈接，讓服務器處理過多信息而DOWN掉，那麼，幹掉一臺WEB服務器的條件就必須有2個：1.有Chargen服務2.有HTTP 服務
方法：攻擊者僞造源IP給N臺Chargen發送鏈接請求（Connect），Chargen接收到鏈接後就會返回每秒72字節的字符流（實際上根據網絡實際狀況，這個速度更快）給服務器。
五、Http指紋識別技術
Http指紋識別的原理大體上也是相同的：記錄不一樣服務器對Http協議執行中的微小差異進行識別.Http指紋識別比TCP/IP堆棧指紋識別複雜許 多,理由是定製Http服務器的配置文件、增長插件或組件使得更改Http的響應信息變的很容易,這樣使得識別變的困難；然而定製TCP/IP堆棧的行爲 須要對核心層進行修改,因此就容易識別.
要讓服務器返回不一樣的Banner信息的設置是很簡單的,象Apache這樣的開放源代碼的Http服務器,用戶能夠在源代碼裏修改Banner信息,然 後重起Http服務就生效了；對於沒有公開源代碼的Http服務器好比微軟的IIS或者是Netscape,能夠在存放Banner信息的Dll文件中修 改,相關的文章有討論的,這裏再也不贅述,固然這樣的修改的效果仍是不錯的.另一種模糊Banner信息的方法是使用插件。
經常使用測試請求：
1：HEAD/Http/1.0發送基本的Http請求
2：DELETE/Http/1.0發送那些不被容許的請求,好比Delete請求
3：GET/Http/3.0發送一個非法版本的Http協議請求
4：GET/JUNK/1.0發送一個不正確規格的Http協議請求
Http指紋識別工具Httprint,它經過運用統計學原理,組合模糊的邏輯學技術,能頗有效的肯定Http服務器的類型.它能夠被用來收集和分析不一樣Http服務器產生的簽名。
六、其餘：爲了提升用戶使用瀏覽器時的性能，現代瀏覽器還支持併發的訪問方式，瀏覽一個網頁時同時創建多個鏈接，以迅速得到一個網頁上的多個圖標，這樣能更快速完成整個網頁的傳輸。
HTTP1.1中提供了這種持續鏈接的方式，而下一代HTTP協議：HTTP-NG更增長了有關會話控制、豐富的內容協商等方式的支持，來提供
更高效率的鏈接。
轉自 http://blog.csdn.net/gueter/article/details/1524447
本條目發佈於
2014年11月12日。屬於
未分類分類。
◆簡介
目的：解決企業應用開發的複雜性
功能：使用基本的JavaBean代替EJB，並提供了更多的企業應用功能
範圍：任何Java應用
Spring 框架是一個分層架構，由 7 個定義良好的模塊組成。Spring 模塊構建在覈心容器之上，核心容器定義了建立、配置和管理 bean 的方式。
組成 Spring 框架的每一個模塊（或組件）均可以單獨存在，或者與其餘一個或多個模塊聯合實現。每一個模塊的功能以下：
• 核心容器：核心容器提供 Spring 框架的基本功能。核心容器的主要組件是 BeanFactory，它是工廠模式的實現。BeanFactory 使用控制反轉 （IOC） 模式將應用程序的配置和依賴性規範與實際的應用程序代碼分開。
• Spring 上下文：Spring 上下文是一個配置文件，向 Spring 框架提供上下文信息。Spring 上下文包括企業服務，例如 JNDI、EJB、電子郵件、國際化、校驗和調度功能。
• Spring AOP：經過配置管理特性，Spring AOP 模塊直接將面向方面的編程功能集成到了 Spring 框架中。因此，能夠很容易地使 Spring 框架管理的任何對象支持 AOP。Spring AOP 模塊爲基於 Spring 的應用程序中的對象提供了事務管理服務。經過使用 Spring AOP，不用依賴 EJB 組件，就能夠將聲明性事務管理集成到應用程序中。
• Spring DAO：JDBC DAO 抽象層提供了有意義的異常層次結構，可用該結構來管理異常處理和不一樣數據庫供應商拋出的錯誤消息。異常層次結構簡化了錯誤處理，而且極大地下降了須要編寫 的異常代碼數量（例如打開和關閉鏈接）。Spring DAO 的面向 JDBC 的異常聽從通用的 DAO 異常層次結構。
• Spring ORM：Spring 框架插入了若干個 ORM 框架，從而提供了 ORM 的對象關係工具，其中包括 JDO、Hibernate 和 iBatis SQL Map。全部這些都聽從 Spring 的通用事務和 DAO 異常層次結構。
• Spring Web 模塊：Web 上下文模塊創建在應用程序上下文模塊之上，爲基於 Web 的應用程序提供了上下文。因此，Spring 框架支持與 Jakarta Struts 的集成。Web 模塊還簡化了處理多部分請求以及將請求參數綁定到域對象的工做。
• Spring MVC 框架：MVC 框架是一個全功能的構建 Web 應用程序的 MVC 實現。經過策略接口，MVC 框架變成爲高度可配置的，MVC 容納了大量視圖技術，其中包括 JSP、Velocity、Tiles、iText 和 POI。
Spring 框架的功能能夠用在任何 J2EE 服務器中，大多數功能也適用於不受管理的環境。Spring 的核心要點是：支持不綁定到特定 J2EE 服務的可重用業務和數據訪問對象。毫無疑問，這樣的對象能夠在不一樣 J2EE 環境 （Web 或 EJB）、獨立應用程序、測試環境之間重用。
◆Spring做爲全方位的應用程序框架(Framework)
◆術語描述
① 輕量級（Lightweight）。Spring 核心包容量不到1MB的大小，能夠在不少小型設備中使用Spring。
② 非侵入性(No intrusive)。加強應用程序組件的可重用性，減小對框架的依賴。
③ 容器（Container）。根據配置文件自動生成對象及屬性等，不用編寫任何代碼來產生對象。
④ Inversion of Control(IOC)與Dependency Injection（DI）。IOC目的就是依賴於抽象；對象之間的關係由容器根據配置文件將依賴注入指定的對象中。
⑤ AOP(Aspect-oriented programming)。基於代理及攔截器的機制，與Spring IOC 結合，採用運行時Weaving方式在Spring框架的應用程序中使用各類聲明式系統級服務。
⑥ 持久層（Persistent）。Spring提供DAO、編程事務與聲明式事務，對於ORM工具（Hibernate、iBATIS）的整合及使用上簡化。
⑦ JavaEE服務。可使用JavaEE標準規範提供的各項服務，並沒有縫結合。
◆Spring框架的優點
① 使J2EE易用和促進好編程習慣。
Spring不從新開發已有的東西。所以，在Spring中你將發現沒有日誌記錄的包,沒有鏈接池,沒有分佈事務調度。這些均有開源項目提供(例如 Commons Logging 用來作全部的日誌輸出，或Commons DBCP用來做數據鏈接池),或由你的應用程序服務器提供。由於一樣的的緣由，咱們沒有提供O/R mapping層，對此，已有好的解決辦法如Hibernate和JPA。
② 使已存在的技術更加易用。
例如,儘管咱們沒有底層事務協調處理，但咱們提供了一個抽象層覆蓋了JTA或任何其餘的事務策略。
③ 沒有直接和其餘的開源項目競爭。
例如，許多開發人員，咱們歷來沒有爲Struts高興過，而且感到在MVC框架中還有改進的餘地。在某些領域，例如輕量級的IoC容器和AOP框架，Spring有直接的競爭，可是在這些領域尚未已經較爲流行的解決方案。(Spring在這些區域是開路先鋒。)
④ Spring在應用服務器之間是可移植的。保證可移植性老是一項挑戰，可是Spring避免任何特定平臺或非標準化,而且支持在WebLogic，Tomcat，Resin，JBoss，WebSphere和其餘的應用服務器上的用戶。
⑤ 方便解耦，簡化開發。
經過Spring提供的IoC容器，咱們能夠將對象之間的依賴關係交由Spring進行控制，避免硬編碼所形成的過分程序耦合。有了Spring，用戶沒必要再爲單實例模式類、屬性文件解析等這些很底層的需求編寫代碼，能夠更專一於上層的應用。
⑥ AOP編程的支持。
經過Spring提供的AOP功能，方便進行面向切面的編程，許多不容易用傳統OOP實現的功能能夠經過AOP輕鬆應付。
⑦ 聲明式事務的支持
在Spring中，咱們能夠從單調煩悶的事務管理代碼中解脫出來，經過聲明式方式靈活地進行事務的管理，提升開發效率和質量。
⑧ 方便程序的測試
能夠用非容器依賴的編程方式進行幾乎全部的測試工做，在Spring裏，測試再也不是昂貴的操做，而是隨手可作的事情。
⑨ 方便集成各類優秀框架
Spring不排斥各類優秀的開源框架，相反，Spring能夠下降各類框架的使用難度，Spring提供了對各類優秀框架（如Struts,Hibernate）等的直接支持。
⑩ 下降Java EE API的使用難度
Spring對不少難用的Java EE API（如JDBC，JavaMail，遠程調用等）提供了一個薄薄的封裝層，經過Spring的簡易封裝，這些Java EE API的使用難度大爲下降。
本文轉自 http://www.iteye.com/topic/583213
本條目發佈於
2014年11月2日。屬於
未分類分類。
HanyuPinyinOutputFormat format = new HanyuPinyinOutputFormat();
// UPPERCASE：大寫 (ZHONG)
// LOWERCASE：小寫 (zhong)
format.setCaseType(HanyuPinyinCaseType.LOWERCASE);
// WITHOUT_TONE：無音標 (zhong)
// WITH_TONE_NUMBER：1-4數字表示英標 (zhong4)
// WITH_TONE_MARK：直接用音標符（必須WITH_U_UNICODE不然異常） (zhòng)
format.setToneType(HanyuPinyinToneType.WITH_TONE_MARK);
// WITH_V：用v表示ü (nv)
// WITH_U_AND_COLON：用"u:"表示ü (nu:)
// WITH_U_UNICODE：直接用ü (nü)
format.setVCharType(HanyuPinyinVCharType.WITH_U_UNICODE);
String[] pinyin = PinyinHelper.toHanyuPinyinStringArray('重', format);
toHanyuPinyinStringArray若是傳入的字符不是漢字不能轉換成拼音，那麼會直接返回null。
本條目發佈於
2014年11月1日。屬於
未分類分類。
在Spring中實現事務管理有兩種方式，一種是傳統的編程式事務管理機制，也就是程序員經過編寫代碼實現事務的管理，具體包括定義事務的開始，在程序異常時進行事務的回滾及程序正常執行後的事務提交。
另外一種則是基於AOP技術實現的聲明式事務管理，事務管理自己是一項共有的系統級服務功能，徹底能夠將事務管理抽象成一個事務切面，程序員再也不關心 事務管理的問題，把主要精力放在覈心業務邏輯代碼的編寫上，而後在須要進行事務管理的方法上切入事務切面，使之具備事務管理的功能，達到事務管理的目的。
Spring的聲明式事務管理在底層是創建在AOP的基礎之上的，其本質是對方法先後進行攔截，而後在目標方法開始以前建立或者加入一個事務，在執行完成目標方法之生根據執行狀況提交或者回滾事務。
Spring中進行事務管理的一般方式是利用AOP的方式，爲普通Java類封裝事務控制，它是經過動態代理實現的，因爲接口是延遲實例化的，Spring在這段時間內經過攔截器加載事務切面，原理就是這樣。
動態代理的一個重要特徵是，它是針對接口的，因此個人dao要經過動態代理來讓Spring接管事務，就必須在dao前面抽象出一個接口，若是沒有這樣的接口，那麼Spring會使用CGLIB一解決問題。
在業務方法上進行@Transactional註解，即可以將事務規則應用到業務邏輯中，由於事務管理自己就是一個典型的切面，正好是AOP技術的用武之地。
依賴注入容器爲聲明式事務管理提供了基礎設施，使得Bean對於Spring框架而言是可管理的。而Spring AOP則是聲明式事務管理的直接實現者。
本條目發佈於
2014年11月1日。屬於
未分類分類。
註解@Retention能夠用來修飾註解，是註解的註解，稱爲元註解。
Retention註解有一個屬性value，是RetentionPolicy類型的，Enum RetentionPolicy是一個枚舉類型，
這個枚舉決定了Retention註解應該如何去保持，也可理解爲Rentention 搭配 RententionPolicy使用。RetentionPolicy有3個值：CLASS RUNTIME SOURCE
用@Retention(RetentionPolicy.CLASS)修飾的註解，表示註解的信息被保留在class文件(字節碼文件)中當程序編譯時，但不會被虛擬機讀取在運行的時候；
用@Retention(RetentionPolicy.SOURCE )修飾的註解,表示註解的信息會被編譯器拋棄，不會留在class文件中，註解的信息只會留在源文件中；
用@Retention(RetentionPolicy.RUNTIME )修飾的註解，表示註解的信息被保留在class文件(字節碼文件)中當程序編譯時，會被虛擬機保留在運行時，
因此他們能夠用反射的方式讀取。RetentionPolicy.RUNTIME 可讓你從JVM中讀取Annotation註解的信息，以便在分析程序的時候使用.
[java] view plaincopy
package com.self;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
@Retention(RetentionPolicy.RUNTIME)
public @interface MyTarget
{ }
定義個一註解@MyTarget，用RetentionPolicy.RUNTIME修飾；
package com.self;
import java.lang.reflect.Method;
public class MyTargetTest
{
@MyTarget
public void doSomething()
{
System.out.println(「hello world」);
}
public static void main(String[] args) throws Exception
{
Method method = MyTargetTest.class.getMethod(「doSomething」,null);
if(method.isAnnotationPresent(MyTarget.class))//若是doSomething方法上存在註解@MyTarget，則爲true
{
System.out.println(method.getAnnotation(MyTarget.class));
}
}
}
上面程序打印：@com.self.MyTarget()，若是RetentionPolicy值不爲RUNTIME,則不打印。
@Retention(RetentionPolicy.SOURCE )
public @interface Override
@Retention(RetentionPolicy.SOURCE )
public @interface SuppressWarnings
@Retention(RetentionPolicy.RUNTIME )
public @interface Deprecated
由上能夠看出，只有註解@Deprecated在運行時能夠被JVM讀取到
註解中能夠定義屬性，看例子：
@Retention(RetentionPolicy.RUNTIME)
public @interface MyAnnotation
{
String hello() default 「gege」;
String world();
int[] array() default { 2, 4, 5, 6 };
EnumTest.TrafficLamp lamp() ;
TestAnnotation lannotation() default @TestAnnotation(value = 「ddd」);
Class style() default String.class;
}
上面程序中，定義一個註解@MyAnnotation，定義了6個屬性，他們的名字爲：
hello,world,array,lamp,lannotation,style.
屬性hello類型爲String,默認值爲gege
屬性world類型爲String,沒有默認值
屬性array類型爲數組,默認值爲2，4，5，6
屬性lamp類型爲一個枚舉,沒有默認值
屬性lannotation類型爲註解,默認值爲@TestAnnotation，註解裏的屬性是註解
屬性style類型爲Class,默認值爲String類型的Class類型
看下面例子:定義了一個MyTest類，用註解@MyAnnotation修飾，註解@MyAnnotation定義的屬性都賦了值
@MyAnnotation(hello = 「beijing」, world=」shanghai」,array={},lamp=TrafficLamp.RED,style=int.class)
public class MyTest
{
@MyAnnotation(lannotation=@TestAnnotation(value=」baby」), world = 「shanghai」,array={1,2,3},lamp=TrafficLamp.YELLOW)
@Deprecated
@SuppressWarnings(「」)
public void output()
{
System.out.println(「output something!」);
}
}
接着經過反射讀取註解的信息：
public class MyReflection
{
public static void main(String[] args) throws Exception
{
MyTest myTest = new MyTest();
Class c = MyTest.class;
Method method = c.getMethod(「output」, new Class[] {});
//若是MyTest類名上有註解@MyAnnotation修飾，則爲true
if(MyTest.class.isAnnotationPresent(MyAnnotation.class))
{
System.out.println(「have annotation」);
}
if (method.isAnnotationPresent(MyAnnotation.class))
{
method.invoke(myTest, null); //調用output方法
//獲取方法上註解@MyAnnotation的信息
MyAnnotation myAnnotation = method.getAnnotation(MyAnnotation.class);
String hello = myAnnotation.hello();
String world = myAnnotation.world();
System.out.println(hello + 「, 」 + world);//打印屬性hello和world的值
System.out.println(myAnnotation.array().length);//打印屬性array數組的長度
System.out.println(myAnnotation.lannotation().value()); //打印屬性lannotation的值
System.out.println(myAnnotation.style());
}
//獲得output方法上的全部註解，固然是被RetentionPolicy.RUNTIME修飾的
Annotation[] annotations = method.getAnnotations();
for (Annotation annotation : annotations)
{
System.out.println(annotation.annotationType().getName());
}
}
}
上面程序打印：
have annotation
output something!
gege, shanghai
3
baby
class java.lang.String
com.heima.annotation.MyAnnotation
java.lang.Deprecated
若是註解中有一個屬性名字叫value,則在應用時能夠省略屬性名字不寫。
可見，@Retention(RetentionPolicy.RUNTIME )註解中，RetentionPolicy.RUNTIME是註解屬性值，屬性名字是value,
屬性的返回類型是RetentionPolicy，以下：
public @interface MyTarget
{
String value();
}
能夠這樣用：
@MyTarget(「aaa」)
public void doSomething()
{
System.out.println(「hello world」);
}
註解@Target也是用來修飾註解的元註解，它有一個屬性ElementType也是枚舉類型，
值爲：ANNOTATION_TYPE CONSTRUCTOR FIELD LOCAL_VARIABLE METHOD PACKAGE PARAMETER TYPE
如@Target(ElementType.METHOD) 修飾的註解表示該註解只能用來修飾在方法上。
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface MyTarget
{
String value() default 「hahaha」;
}
如把@MyTarget修飾在類上，則程序報錯，如：
@MyTarget
public class MyTargetTest
註解大都用在開發框架中吧，好了有關注解就學習那麼多了，謝謝。
本條目發佈於
2014年11月1日。屬於
未分類分類。
支付寶此次面試,直接是一波流搞定,沒有HR問爲毛辭職,職業規劃之類的問題,都是直接上乾貨的,技術.
筆試40分鐘,而後帶上試卷直接去面試,面試時間長短就不清楚了,我大概面了1個小時左右.
筆試:
1. cookie 和 session 的區別
2. JVM 內存模型
3. SQL注入的原理
4. 悲觀鎖 和 樂觀鎖
5. 讀程序,輸出結果. 關於treemap的
6. linux 基礎命令,統計日誌中的信息
7. java 分佈式集羣
8. 一道設計題,具體到數據庫的表.大概是淘寶的搜索中,輸入手機,會出來不少類型,按品牌按價格區間按手機種類.
還有2道題我記不住了.
面試:
1.介紹你作過的項目,用到的技術,涉及到的模塊,而後從項目中問各類技術實現的細節(爲了確保你是真的懂了).
2.看你的試卷,喊你講解作題的思路,以及這樣結果的緣由.(考的是各位的java基礎知識了,這點是繞不過去的,懂了就懂了啊,只有平時多看書)
3.團購6位驗證碼以及團購成功後,發送到你手機上的條碼的實現方式.(第一個問題我說用隨機數+時間來驗證.第二個問題老實說,我也沒答上來,我說用序列,面試官說序列到後期20位以上的時候,用戶體驗不好的)
4.淘寶上是如何保證庫存和訂單之間的數據準確性的.(考點是分佈式事務,這個問題我也沒答上來,最後他問我有什麼問題問他的時候,我就反問的這個問題,面試官人挺好的,給我耐心的講解了一遍淘寶的實現方式以及
epay的實現方式. 淘寶是經過分佈式事物,中間用了一個叫協調者角色的程序,當那邊點擊購買時,會庫存減一,保存一條預扣的狀態,可是是個預準備狀態,而後作成功後,協調者會在另外一個數據庫生成訂單,而後這個訂單也是預狀態,等兩邊都
準備好之後,通知協調者,又協調者統一完成這2個數據庫的事物,從而達到完成一筆交易的目的,若其中一方失敗,則將預扣的數字返回到庫存從而實現相似回滾的操做.)
5.索引的原理.可否構建時間索引.時間索引構建後會存在什麼問題.(索引原理我是回答的堆表索引的構建原理以及查詢原理,可是關於時間索引的問題,我也沒回答出個因此然來,看面試官的反饋,好像回答得不夠好吧)
6.大家數據庫的數據量有多大,(回答:咱們是電信方面的系統,表上億的數據很正常).問:若是保證效率?
(我是如此回答的,各位自行結合自身的狀況參考.答:後臺JOB程序會按期備份,把生產表數據移走,而後備份表也會再備份一次,如此剃度的備份,保證生產庫的數據是最小的.而後備份表採用分區和子分區,加上構建戰略索引(分析系統的sql,經常使用
查詢字段構建複合索引,以減小每次查詢時對錶的訪問次數)).
7.SQL注入的原理以及如何預防,並舉例.(這個相對簡單,網上一搜一大片)
8.使用過Memcache麼? 用在項目中哪些地方? (答,在門戶主機上使用,緩存session,分佈式的時候,統一訪問這臺主機驗證用戶session是否存在,來維持回話的狀態和實現回話同步.又追 問:java代碼中如何實現訪問門戶服務器的這個session池子的? 幾年前的代碼,確實忘記了..因而坦白的說,記不清楚了 )
這些是主要的問題,當你回答一個大問題時中間還有不少比較碎的追問性質的小問題,整體給個人感受是,氛圍很輕鬆+愉快的,技術層面上仍是須要你真正的理解透徹一些關鍵技術點,才能作到應付各類追問和給出滿意的答案吧.若是隻是隻知其一;不知其二想去矇混過關確定
是不行的,畢竟在支付寶的技術大牛面前,多追問幾句,也就把你逼到死角了.
還有一點比較重要的感受就是,他們比較在乎你是否瞭解當下的一些比較熱的技術點,好比淘寶的秒殺,是如何保證高併發下的安全性和性能,新浪微博那種大數據量的發送,怎麼就保證正確性和時效性的.
自我感受面試得很通常,估計但願比較小吧,共享這些但願能給各位小夥伴帶來實際上的幫助
本文轉自 http://www.mianwww.com/html/2014/02/19431.html
本條目發佈於
2014年11月1日。屬於
未分類分類。
