Chrome原始碼分析之socket（一）

阿新 • • 發佈：2019-01-15

作為對HTTP連線的分析，首先跟蹤一下Chrome對一個新的URL請求的處理流程。

從Chrome的實現來看，對一個URL資源的請求是放在Browser程序中來實現的，而不是由各個Render程序來實現，據說開發文件中提到這樣做的三個主要優勢，一是避免子程序進行網路通訊，增加安全性，二是有利於Cookie等持久化資源在不同頁面中的共享，否則在不同Render程序中傳遞Cookie比較麻煩，第三是由Browser統一進行網路通訊可以減少HTTP連線的數量。
一般來說，當你在位址列輸入URL地址並且回車確認之後，由於AutocompleteEditViewWin繼承自ATL的CRichEditCtrl類，因而他也擁有了訊息對映的能力，在訊息對映的控制下，最終OnKeyDownOnlyWritable函式被呼叫了，OnKeyDownOnlyWritable裡面的通過switch對各種按鍵分別處理，如果是回車鍵，就呼叫model_->AcceptInput，這個函式要對傳入的URL地址做一些簡單判斷，由於中間的呼叫過程比較漫長,這裡不對每個函式進行分析了,只把呼叫流程列出來：
src\chrome\browser\autocomplete\autocomplete_edit.cc #351view_->OpenURL
src\chrome\browser\autocomplete\autocomplete_edit_view_win.cc #612 model_->OpenURL
src\chrome\browser\autocomplete\autocomplete_edit.cc #612 model_->OpenURL，
src\chrome\browser\autocomplete\autocomplete_edit.cc #412 controller_->OnAutocompleteAccept。
src\chrome\browser\views\location_bar\location_bar_view.cc #791 command_updater_->ExecuteCommand(IDC_OPEN_CURRENT_URL);
src\chrome\browser\command_updater.cc #45 delegate_->ExecuteCommand(id);
src\chrome\browser\browser.cc #2318 ExecuteCommandWithDisposition(id, CURRENT_TAB);
src\chrome\browser\browser.cc #1245 browser::Navigate(&params);
src\chrome\browser\browser_navigator.cc #324 params->target_contents->controller().LoadURL
src\chrome\browser\tab_contents\navigation_controller.cc #496 LoadEntry(entry);
src\chrome\browser\tab_contents\navigation_controller.cc #282 NavigateToPendingEntry(NO_RELOAD);
src\chrome\browser\tab_contents\navigation_controller.cc #1039 tab_contents_->NavigateToPendingEntry(reload_type)
src\chrome\browser\tab_contents\tab_contents.cc #853 NavigateToEntry(*controller_.pending_entry(), reload_type);
src\chrome\browser\tab_contents\tab_contents.cc #891 dest_render_view_host->Navigate(navigate_params);
src\chrome\browser\renderer_host\render_view_host.cc #250 Send(nav_message);
我們看看最後2行， dest_render_view_host->Navigate(navigate_params);發生在TabContents::NavigateToEntry函式中，dest_render_view_host是一個指標，在函式開始的時候通過呼叫render_manager_.Navigate(entry)得到，我們知道在Chrome的程序模型裡面，Browser程序管理其他程序和頁面，一個程序就是一個RenderProcessHost例項，一個頁面就是一個RenderViewHost例項。而頁面實際上是承載在RenderProcess上的，一個RenderProcess上可以有多個RenderView。render_manager_是TabContents中負責管理RenderViewHost的類，這裡它返回一個可用的RenderViewHost例項，RenderViewHost收集於此次URL請求相關的所有資訊，生成一個訊息並通過IPC機制傳送給對於的RenderProcess，在Send之前的函式呼叫都發生在Browser程序的MainThread中，當需要傳送訊息給RenderProcess的時候則進入了I/O Thread 的領域內。至於IPC機制我們留到以後再分析。
訊息傳送出去以後，接收訊息的應該是RenderProcess的RenderThread和RenderView，訊息首先在RenderProcess裡面經過分類和路由，後來傳到給了RenderView的
OnMessageReceived函式，下面繼續列出流程：
src\chrome\renderer\render_view.cc #764 IPC_MESSAGE_HANDLER(ViewMsg_Navigate, OnNavigate)
src\chrome\renderer\render_view.cc #1226 main_frame->loadRequest(request);
src\third_party\WebKit\WebKit\chromium\src\WebFrameImpl.cpp #883 m_frame->loader()->load(resourceRequest, false);
src\third_party\WebKit\WebCore\loader\FrameLoader.cpp #1362 load(request, SubstituteData(), lockHistory);
src\third_party\WebKit\WebCore\loader\FrameLoader.cpp #1375 load(loader.get());
src\third_party\WebKit\WebCore\loader\FrameLoader.cpp #1433 loadWithDocumentLoader(newDocumentLoader, type, 0);
src\third_party\WebKit\WebCore\loader\FrameLoader.cpp #1477 continueLoadAfterNavigationPolicy(loader->request(), formState, false);
src\third_party\WebKit\WebCore\loader\FrameLoader.cpp #2975 continueLoadAfterWillSubmitForm();
src\third_party\WebKit\WebCore\loader\FrameLoader.cpp #2463 m_provisionalDocumentLoader->startLoadingMainResource(identifier)
src\third_party\WebKit\WebCore\loader\DocumentLoader.cpp #765 m_mainResourceLoader->load(m_request, m_substituteData)
src\third_party\WebKit\WebCore\loader\MainResourceLoader.cpp#583 loadNow(request)
src\third_party\WebKit\WebCore\loader\MainResourceLoader.cpp #556 ResourceHandle::create
src\third_party\WebKit\WebKit\chromium\src\ResourceHandle.cpp #223 newHandle->start(context)
src\third_party\WebKit\WebKit\chromium\src\ResourceHandle.cpp #251 d->start();
src\third_party\WebKit\WebKit\chromium\src\ResourceHandle.cpp #111 m_loader->loadAsynchronously(wrappedRequest, this);
src\webkit\glue\weburlloader_impl.cc #717 context_->Start(request, NULL);
src\webkit\glue\weburlloader_impl.cc #476 bridge_->Start(this)
src\chrome\common\resource_dispatcher.cc #186 dispatcher_->message_sender()->Send
到了這裡，通過IPC機制將頁面渲染的請求再封裝為一個訊息，傳送給Browser程序。當然在呼叫dispatcher_->message_sender()->Send之前程式碼依然在RenderThread上執行，不過訊息的傳送實際上是在MainThread中進行的，其中的原因在IPC機制中再行分析。
作為接受訊息的Browser程序，這個訊息首先I/O Thrad中被處理，然後轉發給MainThread，MainThread再進行一些處理最後對映到ResourceDispatcherHost的OnMessageReceived函式。

src\chrome\browser\renderer_host\resource_dispatcher_host.cc #542 BeginRequestInternal(request);
src\chrome\browser\renderer_host\resource_dispatcher_host.cc #1310 InsertIntoResourceQueue(request, *info);
src\chrome\browser\renderer_host\resource_dispatcher_host.cc #1316 resource_queue_.AddRequest(request, request_info);
src\chrome\browser\renderer_host\resource_queue.cc #62 request->Start();
src\net\url_request\url_request.cc #307 StartJob(GetJobManager()->CreateJob(this));
src\net\url_request\url_request.cc #336 job_->Start();
src\net\url_request\url_request_http_job.cc #159 AddCookieHeaderAndStart();
src\net\url_request\url_request_http_job.cc #739 OnCanGetCookiesCompleted(policy);
src\net\url_request\url_request_http_job.cc #460 StartTransaction();
src\net\url_request\url_request_http_job.cc #632 transaction_->Start
src\net\http\http_network_transaction.cc #144 DoLoop(OK);
src\net\http\http_network_transaction.cc #446 DoCreateStream();
src\net\http\http_network_transaction.cc #449 DoCreateStreamComplete(rv);
src\net\http\http_network_transaction.cc #456 DoInitStreamComplete(rv);
src\net\http\http_network_transaction.cc #463 DoGenerateProxyAuthTokenComplete(rv);
src\net\http\http_network_transaction.cc #470 DoGenerateServerAuthTokenComplete(rv);
src\net\http\http_network_transaction.cc #475 DoSendRequest();
src\net\http\http_network_transaction.cc #646 stream_->SendRequest
src\net\http\http_basic_stream.cc #48 parser_->SendRequest
src\net\http\http_stream_parser.cc #63 DoLoop(OK)
src\net\http\http_stream_parser.cc #145 DoSendHeaders(result);
src\net\http\http_stream_parser.cc #228 connection_->socket()->Write

request->Start()函式這裡進入網路通訊部分,從connection_->socket()->Write開始詳細分析。
這裡的Write呼叫實際上是TCPClientSocketWin類的成員函式，函式傳入的三個引數分別是傳送快取buf,快取長度buf_len,回撥函式指標callback。

接著用下面的程式碼將傳送資料儲存起來

core_->write_buffer_.len = buf_len;
core_->write_buffer_.buf = buf->data();
core_->write_buffer_length_ = buf_len;
core_是TCPClientSocketWin的成員變數，實際上是一個類，在TCPClientSocketWin讀寫網路資料的過程中發揮這核心作用，先看看core_的定義：
class TCPClientSocketWin::Core : public base::RefCounted<Core> {
public:
explicit Core(TCPClientSocketWin* socket);
void WatchForRead();
void WatchForWrite();
void Detach() { socket_ = NULL; }
OVERLAPPED read_overlapped_;
OVERLAPPED write_overlapped_;
WSABUF read_buffer_;
WSABUF write_buffer_;
scoped_refptr<IOBuffer> read_iobuffer_;
scoped_refptr<IOBuffer> write_iobuffer_;
int write_buffer_length_;
int ThrottleReadSize(int size) {
if (slow_start_throttle_ < kMaxSlowStartThrottle) {
size = std::min(size, slow_start_throttle_);
slow_start_throttle_ *= 2;
}
return size;
}
private:
friend class base::RefCounted<Core>;
class ReadDelegate : public base::ObjectWatcher::Delegate {
public:
explicit ReadDelegate(Core* core) : core_(core) {}
virtual ~ReadDelegate() {}
virtual void OnObjectSignaled(HANDLE object);
private:
Core* const core_;
};
class WriteDelegate : public base::ObjectWatcher::Delegate {
public:
explicit WriteDelegate(Core* core) : core_(core) {}
virtual ~WriteDelegate() {}
virtual void OnObjectSignaled(HANDLE object);
private:
Core* const core_;
};
~Core();
TCPClientSocketWin* socket_;
ReadDelegate reader_;
WriteDelegate writer_;
base::ObjectWatcher read_watcher_;
base::ObjectWatcher write_watcher_;
static const int kInitialSlowStartThrottle = 1 * 1024;
static const int kMaxSlowStartThrottle = 32 * kInitialSlowStartThrottle;
int slow_start_throttle_;
DISALLOW_COPY_AND_ASSIGN(Core);
};
總的來說類Core的作用就是為基於事件通知非同步I/O的TCP連線提供和協調所有相關的事件物件，傳送接收快取，執行緒池控制以及回撥處理等相關功能。其中OVERLAPPED read_overlapped_和OVERLAPPED write_overlapped_分別是讀寫的重疊I/O控制變數，WSABUF read_buffer_和WSABUF write_buffer_維護讀寫的快取。

在Core還在類體中即時定義了2個私有類:class ReadDelegate : public base::ObjectWatcher::Delegate和class WriteDelegate : public base::ObjectWatcher::Delegate。這2個類都只有一個成員函式OnObjectSignaled，這個函式在Chrome自建執行緒的訊息迴圈中將被呼叫。至於OnObjectSignaled為什麼會被呼叫，這跟另外兩個成員變數base::ObjectWatcher read_watcher_和base::ObjectWatcher write_watcher_直接相關，後面再詳細分析。

我們接著全面分析一下TCPClientSocketWin類，先看看它是如何建立一個TCP連線，TCPClientSocketWin首先呼叫成員函式Connect，它只是簡單的設定next_connect_state_的狀態，以及給current_ai_賦值，current_ai_是一個addrinfo型別的結構體，addrinfo相容IPV4以及IPV6的地址資訊，因此我們可以透明化的處理這2個協議族的地址。接著呼叫DoConnectLoop這個函式，再看看DoConnectLoop的實現，只有一個簡單的迴圈，首先呼叫DoConnect，如果連線立即成功的話接著呼叫DoConnectComplete，否則返回一個ERR_IO_PENDING顯示連線請求處於異步出流流程中，或者是呼叫失敗，返回錯誤程式碼。

下面看看DoConnect()函式的實現，不僅僅因為在寫入資料之前需要呼叫connect來接連新連線，而且在這個函式中還初始化了套介面的非同步I/O模型，下面看看這個函式的主要程式碼：

#1 int TCPClientSocketWin::DoConnect() {
#2 const struct addrinfo* ai = current_ai_;
#3   DCHECK(ai);
#4   DCHECK_EQ(0, connect_os_error_);
#5   if (previously_disconnected_) {
#6   use_history_.Reset();
#7 previously_disconnected_ = false;
#8 }
#9 net_log_.BeginEvent(NetLog::TYPE_TCP_CONNECT_ATTEMPT,
#10   new NetLogStringParameter(
#11 "address", NetAddressToStringWithPort(current_ai_)));//這裡寫入之日方便除錯
#12   next_connect_state_ = CONNECT_STATE_CONNECT_COMPLETE;
#13   connect_os_error_ = CreateSocket(ai); //建立新的socket
#14   if (connect_os_error_ != 0)
#15   return MapWinsockError(connect_os_error_);
#16   DCHECK(!core_);
#17   core_ = new Core(this); //建立一個core_
#18   core_->read_overlapped_.hEvent = WSACreateEvent(); //建立重疊I/O結構
#19   WSAEventSelect(socket_, core_->read_overlapped_.hEvent, FD_CONNECT);//初始化I/O模型，WSAEventSelect是一個非同步I/O模型，具體可以參考MSDN等材料的說明
#20   core_->write_overlapped_.hEvent = WSACreateEvent();
#21   if (!connect(socket_, ai->ai_addr, static_cast<int>(ai->ai_addrlen))) {//非同步模式下connect呼叫後立即返回
#22 NOTREACHED();
#23   if (ResetEventIfSignaled(core_->read_overlapped_.hEvent))
#24   return OK;
#25   } else {
#26   int os_error = WSAGetLastError();
#27 if (os_error != WSAEWOULDBLOCK) {
#28 LOG(ERROR) << "connect failed: " << os_error;
#29   connect_os_error_ = os_error;
#30   return MapConnectError(os_error);
#31   }
#32   }
#34   core_->WatchForRead(); //這裡安裝回調函式
#35   return ERR_IO_PENDING;

#36 }

在第十三行呼叫CreateSocket建立一個新的套介面，接著建立一個Core的物件core_,並給read_overlapped_和write_overlapped_分別建立用於非同步I/O的事件物件，在19行初始化WSAEventSelect模型，用於實現connect的非同步呼叫，根據微軟的文件，一旦呼叫了WSAEventSelect，目標套介面將轉為非阻塞模式,connect不再等待伺服器的響應而是立即返回，返回值是SOCKET_ERRORE,應該說connect永遠不會返回0,但是在這裡他們仍對返回0的情況做了處理，呼叫ResetEventIfSignaled來判斷事件物件是否處於已傳信狀態，還可以看到，connect與read共用了read_overlapped_，因此在Core::ReadDelegate::OnObjectSignaled函式中，會區分connect和read並分別呼叫相應的處理函式。最後34行呼叫core_->WatchForRead()講這個連線交給執行緒模型，如果連線成功的話，DidCompleteConnect將被呼叫，最後呼叫DoReadCallback通知上層的呼叫者。

Chrome原始碼分析之socket（一）

Chrome原始碼分析之socket（一）

java原始碼剖析之socket（一）

kubernetes 原始碼分析之ingress（一）

Java集合原始碼分析之Queue（一）：超級介面Queue_一點課堂（多岸學院）

Dubbo原始碼分析之 SPI（一）

資料庫中介軟體 Sharding-JDBC 原始碼分析 —— SQL 解析（一）之詞法解析

精盡Spring MVC原始碼分析 - HandlerMapping 元件（一）之 AbstractHandlerMapping

精盡Spring MVC原始碼分析 - HandlerAdapter 元件（一）之 HandlerAdapter

java集合類源碼分析之List（一）

【集合框架】JDK1.8源碼分析之HashMap（一）轉載

Lua原始碼分析 Gc篇（一）原理

開源網站流量統計系統Piwik原始碼分析——引數統計（一）

JUC原始碼分析-集合篇（一）：ConcurrentHashMap

ArrayList集合（JDK1.8）【集合框架】JDK1.8原始碼分析之ArrayList（六）

SpringOauth2.0原始碼分析之儲存（五）

Spring 原始碼分析(三) —— AOP（一）AOP原理

看透SpringMVC原始碼分析與實踐（一）

springMVC原始碼分析--國際化LocaleResolver（一）

SPRING原始碼學習之路（一）

elasticsearch原始碼分析之Transport（五）

Chrome原始碼分析之socket（一）

相關推薦