WebDriver是W3C的一個標准，由Selenium主持。
具體的協議標准可以從http://code.google.com/p/selenium/wiki/JsonWireProtocol#Command_Reference 查看。
從這個協議中我們可以看到，WebDriver之所以能夠實現與瀏覽器進行交互，是因為瀏覽器實現了這些協議。這個協議是使用JOSN通過HTTP進行傳輸。
它的實現使用了經典的Client-Server模式。客戶端發送一個requset，服務器端返回一個response。
我們明確幾個概念。
Client
調用 WebDriverAPI的機器。
Server
運行瀏覽器的機器。Firefox瀏覽器直接實現了WebDriver的通訊協議，而Chrome和IE則是通過ChromeDriver和InternetExplorerDriver實現的。
Session
服務器端需要維護瀏覽器的Session，從客戶端發過來的請求頭中包含了Session信息，服務器端將會執行對應的瀏覽器頁面。
WebElement
這是WebDriverAPI中的對象，代表頁面上的一個DOM元素。
舉個實際的例子，下面代碼的作用是”命令”firefox轉跳到google主頁：
WebDriver driver = new FirefoxDriver();
//實例化一個Driver
driver.get("http://www.google.com");
在執行driver.get("http://www.google.com")這句代碼時，client，也就是我們的測試代碼向remote server發送了如下的請求：
POSTsession/285b12e4-2b8a-4fe6-90e1-c35cba245956/url post_data{"url":"http://google.com"}
通過post的方式請求localhost:port/hub/session/session_id/url地址，請求瀏覽器完成跳轉url的操作。
如果上述請求是可接受的，或者說remote server是實現了這個接口，那么remote server會跳轉到該post data包含的url,並返回如下的response
{"name":"get","sessionId":"285b12e4-2b8a-4fe6-90e1-c35cba245956","status":0,"value":""}
該response中包含如下信息
name：remote server端的實現的方法的名稱，這里是get，表示跳轉到指定url；
sessionId：當前session的id；
status：請求執行的狀態碼，非0表示未正確執行，這里是0，表示一切ok不許擔心；
value：請求的返回值，這里返回值為空，如果client調用title接口，則該值應該是當前頁面的title；
如果client發送的請求是定位某個特定的頁面元素，則response的返回值可能是這樣的：
{"name":"findElement","sessionId":"285b12e4-2b8a-4fe6-90e1-c35cba245956","status":0,"value":{"ELEMENT":"{2192893e-f260-44c4-bdf6-7aad3c919739}"}}
name,sessionId，status跟上面的例子是差不多的，區別是該請求的返回值是ELEMENT:{2192893e-f260-44c4-bdf6-7aad3c919739}，表示定位到元素的id，通過該id，client可以發送如click之類的請求與 server端進行交互。
WebDriver與之前Selenium的JS注入實現不同，直接利用了瀏覽器native support來操作瀏覽器。所以對於不同平台，不同的瀏覽器，必須依賴一個特定的瀏覽器的native component來實現把WebDriver API的調用轉化為瀏覽器的native invoke。
在我們new一個WebDriver的過程中，Selenium首先會確認瀏覽器的native component是否存在可用而且版本匹配。接着就在目標瀏覽器里啟動一整套Web Service，這套Web Service使用了Selenium自己設計定義的協議，名字叫做The WebDriver Wire Protocol。這套協議非常之強大，幾乎可以操作瀏覽器做任何事情，包括打開、關閉、最大化、最小化、元素定位、元素點擊、上傳文件等等等等。
WebDriver Wire協議是通用的，也就是說不管是FirefoxDriver還是ChromeDriver，啟動之后都會在某一個端口啟動基於這套協議的Web Service。例如FirefoxDriver初始化成功之后，默認會從http://localhost:7055開始，而ChromeDriver 則大概是http://localhost:46350之類的。接下來，我們調用WebDriver的任何API，都需要借助一個ComandExecutor發送一個命令，實際上是一個HTTP request給46350端口上的Web Service。在我們的HTTP request的body中，會以WebDriver Wire協議規定的JSON格式的字符串來告訴Selenium我們希望瀏覽器接下來做什么事情。
不同瀏覽器的WebDriver子類，都需要依賴特定的瀏覽器原生組件，例如Firefox就需要一個add-on名字叫webdriver.xpi。而IE的話就需要用到一個dll文件來轉化Web Service的命令為瀏覽器native的調用。
關於WebDriver Wire協議的細節，比如希望了解這套Web Service能夠做哪些事情，可以閱讀Selenium官方的協議文檔， 在Selenium的源碼中，我們可以找到一個HttpCommandExecutor這個類，里面維護了一個Map， 它負責將一個個代表命令的簡單字符串key，轉化為相應的URL，因為REST的理念是將所有的操作視作一個個狀態，每一個狀態對應一個URI。所以當我 們以特定的URL發送HTTP request給這個RESTful web service之后，它就能解析出需要執行的操作。截取一段源碼如下：
nameToUrl = ImmutableMap.<String, CommandInfo>builder() .put(NEW_SESSION, post("/session")) .put(QUIT, delete("/session/:sessionId")) .put(GET_CURRENT_WINDOW_HANDLE, get("/session/:sessionId/window_handle")) .put(GET_WINDOW_HANDLES, get("/session/:sessionId/window_handles")) .put(GET, post("/session/:sessionId/url")) // The Alert API is still experimental and should not be used. .put(GET_ALERT, get("/session/:sessionId/alert")) .put(DISMISS_ALERT, post("/session/:sessionId/dismiss_alert")) .put(ACCEPT_ALERT, post("/session/:sessionId/accept_alert")) .put(GET_ALERT_TEXT, get("/session/:sessionId/alert_text")) .put(SET_ALERT_VALUE, post("/session/:sessionId/alert_text"))
可以看到實際發送的URL都是相對路徑，后綴多以/session/:sessionId開頭，這也意味着WebDriver每次啟動瀏覽器都會分 配一個獨立的sessionId，多線程並行的時候彼此之間不會有沖突和干擾。例如我們最常用的一個WebDriver的 API，getWebElement在這里就會轉化為/session/:sessionId/element這個URL，然后在發出的HTTP request body內再附上具體的參數比如by ID還是CSS還是Xpath，各自的值又是什么。收到並執行了這個操作之后，也會回復一個HTTP response。內容也是JSON，會返回找到的WebElement的各種細節，比如text、CSS selector、tag name、class name等等。