Hiểu cổng: Làm thế nào để nhiều tab trình duyệt giao tiếp cùng một lúc? [đóng cửa]


18

Hôm nay tôi nhận ra rằng về cơ bản tôi không hiểu cách thức hoạt động của giao tiếp cảng.

Nếu tôi kích hoạt một phiên bản của máy chủ web nghe trên cổng 80, nó có thể đáp ứng nhiều yêu cầu từ nhiều tab trình duyệt khác nhau, tất cả đều giao tiếp qua cổng 80.

Tuy nhiên, tôi không thể khởi động hai phiên bản của máy chủ, cả hai đều nghe trên cổng 80, vì nó dẫn đến xung đột cổng.

Tôi đã luôn coi đây là một sự nhất định, (chỉ một quá trình có thể liên kết với một cổng cụ thể tại bất kỳ thời điểm nào) mà không bao giờ thực sự nghĩ về nó - không có nhiều quá trình giao tiếp trên cổng 80? (ví dụ: mỗi tab đang chạy trong trình duyệt?)

Câu trả lời:


24

Về cơ bản, chỉ có một quá trình có thể LẮNG NGHE trên một cổng tại một thời điểm (về mặt kỹ thuật, một ổ cắm được dành riêng để nghe). Nhưng, một cổng có thể xử lý nhiều ổ cắm truyền dữ liệu, một ổ cắm là sự kết hợp của IP / cổng cục bộ và địa chỉ IP từ xa / cổng từ xa. Theo cách đó, một khi máy chủ chấp nhận kết nối đến trong khi LẮNG NGHE, nó sẽ mở một ổ cắm mới dành riêng cho cuộc trò chuyện đó và chuyển việc xử lý sang một thứ khác, sau đó quay lại LISTENing.

Chi tiết hơn ở đây .


Trên thực tế bạn có thể có nhiều quá trình nghe trên cùng một cổng. Nếu bạn làm điều đó với nhiều trình đọc udp chẳng hạn, bạn sẽ có được sự cân bằng tải ở cấp độ kernel. Đầu tiên mở ổ cắm để nghe, sau đó rẽ nhánh và cố gắng recv()trong từng quy trình.
viraptor

5
@viraptor: Đúng, nhưng vì UDP không có kết nối, nên thực sự không có sự phân biệt giữa "nghe" và "nhận".
Adam Robinson

Cùng một ý tưởng hoạt động với TCP, quá trình chuyển đổi với ổ cắm nghe và chấp nhận () trên cả hai.
viraptor

Trên thực tế, một ổ cắm chỉ là một "điểm cuối" để liên lạc. Tôi đoán những gì bạn muốn nói là một ổ cắm được kết nối là sự kết hợp của IP / cổng cục bộ và IP / địa chỉ / cổng từ xa. Ổ cắm từ thường được sử dụng đến nỗi tôi khó có thể hiểu được mô tả thực sự của nó là gì
westoque

14

Trình duyệt kết nối từ cổng cao ngẫu nhiên (tức là> 1024) trên máy tính của bạn với cổng 80 của máy chủ từ xa. Do đó, không có xung đột cổng trên máy của bạn.

Nếu bạn sử dụng nhiều tab để kết nối với cùng một máy chủ từ xa (hoặc có nhiều người dùng kết nối với máy chủ) thì tất cả đều đi đến cùng một cổng và được phục vụ theo cùng một quy trình (ví dụ: máy chủ web của trang web).


2
Đây là câu trả lời chính xác. Kết nối TCP có số cổng ở cả hai đầu. Cả hai máy tính liên quan đều có thể phân biệt giữa trang web kết nối: 80 <-> trình duyệt: 12394 và trang web kết nối khác nhau: 80 <-> trình duyệt: 22958.
pjc50

7

Máy chủ lắng nghe trên cổng 80 KHÔNG CÓ để xử lý nhiều quy trình. Trình nền TCP đơn giản của các năm cũ chỉ có thể xử lý một kết nối tại một thời điểm. Bạn có thể mô phỏng hành vi này bằng cách có một chương trình như netcatnghe trên một cổng cụ thể và cố gắng kết nối hai máy với nó. Một cái sẽ vào trong, cái kia sẽ bật ra mà không có kết nối. Những daemon này hầu như vô dụng nên bạn không bao giờ nhìn thấy chúng nữa.

Đối với một cái gì đó giống như một máy chủ web, nó nghe trực tiếp trên cổng. Điều cần lưu ý là nó đang nằm trên thư viện ổ cắm của hệ điều hành. Khi một kết nối mới được thiết lập, thư viện ổ cắm chuyển ổ cắm hoàn toàn mới cho phần mềm máy chủ web. Tại thời điểm đó, phần mềm máy chủ web có một số tùy chọn.

Một khả năng là nó chuyển đối tượng socket sang một luồng mới trong cùng tiến trình. Bất cứ khi nào giao tiếp xảy ra trên ổ cắm này, chủ đề này sẽ xử lý nó. Quá trình cha mẹ làm trung gian cho các luồng đang hoạt động tại bất kỳ thời điểm nào, có thể rất nhiều.

Một khả năng khác là nó tạo ra một tiến trình mới và truyền đối tượng socket vào tiến trình. Theo tôi hiểu, giờ đây hệ thống ổ cắm của hệ điều hành đã giao tiếp qua trung gian giữa các quy trình con này và các mục tiêu của chúng. Quá trình cha mẹ vẫn có một số kiểm soát đối với các quy trình, chẳng hạn như tiêu diệt các hung và các thông tin liên lạc giữa các quá trình khác.

Phương pháp nào trong số các phương pháp này hiệu quả hơn phụ thuộc vào hệ điều hành. IIRC, Apache có thể chạy ở một trong hai chế độ.

Về bản chất, thư viện socket cung cấp một mức xử lý song song cho máy chủ web. Nó có thể xử lý nhiều kết nối đồng thời chủ động truyền dữ liệu, đồng thời chấp nhận các kết nối mới.

Đối với một trình duyệt có thể tăng tốc nhiều lần thử kết nối với máy chủ web để cải thiện thời gian tải, tính song song cũng được áp dụng ở cuối trình duyệt, đây là một điều tốt và tuyệt vời. Trình duyệt theo dõi trạng thái của trang khi nó đang tải và nhiều lần thử kết nối mà nó tạo ra là tất cả quá trình.


+1 vì đã đúng theo nhiều cách :)
Michael Lowman

2

Có hai "loại" ổ cắm luồng một cách hiệu quả. Một cái có một thẻ "đầu kia", một đầu có một máy chủ cụ thể: cổng cho đầu kia.

Không có hai ổ cắm nào có thể (hoặc, đúng hơn là bao giờ) có cùng số nhận dạng "đầu này" và "đầu kia". Ổ cắm được "lắng nghe" (chấp nhận các kết nối đến) là ổ cắm có "đầu kia", vì vậy chỉ có một đầu vào một lúc có thể tồn tại. Khi kết nối đến, một kết thúc acceptđược thực hiện, trả lại một ổ cắm với một máy chủ: cổng tuple cho đầu kia.


1

Câu hỏi của bạn làm tôi nhớ lại bản thân mình vài năm trước khi Cisco CCNA - có cùng nghi ngờ :)

Trước hết, việc thiết lập nhiều kết nối HTTP không nhất thiết phải gắn với số lượng tab bạn đã mở trong trình duyệt của mình. Ví dụ: khi truy cập một trang web có quảng cáo hoặc mã phân tích google, bạn sẽ kết nối với nhiều trang mặc dù chỉ ở trong một tab.

Dù sao, khi trình duyệt của bạn giao tiếp với máy chủ web, cổng đích của lưu lượng được gửi đến máy chủ web, là cổng 80, trong khi cổng nguồn là một số ngẫu nhiên. Cổng nguồn là để cho máy chủ web biết cổng nào anh ấy sẽ liên lạc lại với bạn tại. Mỗi kết nối được thiết lập http sẽ mở cổng riêng trên máy tính của bạn. Hãy thử chạy netstat với một vài trang web mở và bạn sẽ thấy ngay ý tôi là gì.

Bạn có thể cười nhưng này cuốn sách là một cách tuyệt vời và nhanh chóng để có được những điều cơ bản xuống của TCP / IP. Nó đã giúp tôi rất nhiều.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.