Cổng 80 đang được sử dụng bởi HỆ THỐNG (PID 4), đó là gì?

Tôi đang cố gắng sử dụng cổng 80 cho máy chủ ứng dụng của mình, nhưng khi tôi thực hiện "netstat -aon" thì tôi nhận được

TCP 0.0.0.0:80 0.0.0.0 0 LẮNG NGHE 4

Khi tôi tra cứu quy trình trong trình quản lý tác vụ, nó hiển thị PID 4 là HỆ THỐNG, không phải là phần mở rộng ... không có gì, chỉ là "HỆ THỐNG". Những gì đang xảy ra ở đây?

Tôi sợ kết thúc quá trình này, tôi phải làm gì?

Mặc dù mọi người đang chỉ ra các dịch vụ cụ thể (ví dụ: "Dịch vụ đại lý triển khai web"), nhưng điều này không giải quyết được nguyên nhân gốc. Nếu bạn chỉ vô hiệu hóa các dịch vụ gây ra sự cố, rất có thể nó sẽ quay đầu lại trong tương lai theo một chiêu bài khác. Vì vậy, đáng để hiểu những gì đang xảy ra, bởi vì điều đó dẫn đến một sửa chữa tốt hơn.

Vấn đề này phát sinh khi một máy chủ ứng dụng muốn kiểm soát toàn bộ cổng 80. Điều này mâu thuẫn với một tính năng của Windows được thiết kế để cho phép nhiều quy trình xử lý các yêu cầu trên cổng 80. Hoàn toàn có thể có bất kỳ số lượng quy trình nào nhận được yêu cầu HTTP trên cổng 80, vì Windows có cơ chế gửi HTTP tích hợp. Mỗi quy trình có thể cho Windows biết URL nào nó muốn xử lý.

Tuy nhiên, nếu một máy chủ ứng dụng hoàn toàn bỏ qua điều này, thì bạn sẽ quay lại thế giới ổ cắm trường học kém linh hoạt hơn, nơi chỉ có một quy trình có thể nhận được yêu cầu dành cho bất kỳ cổng cụ thể nào.

Điều đó có thể ổn - nếu bạn thực sự không muốn bất cứ điều gì ngoài quy trình xử lý yêu cầu HTTP cụ thể trên cổng 80, thì có thể chấp nhận sử dụng máy chủ ứng dụng không hỗ trợ các cơ chế linh hoạt hơn do Windows cung cấp. (Và một số máy chủ ứng dụng phổ biến có giới hạn này. Ví dụ: AFAIK, Tomcat không có khả năng chơi tốt với người khác và khăng khăng đòi có cổng 80 cho riêng mình. Vì vậy, nếu bạn đang sử dụng máy chủ ứng dụng của người khác, điều đó có thể không thực tế thích ứng với nó để sử dụng cơ chế ưa thích.)

Windows cố gắng đáp ứng các dịch vụ không linh hoạt như vậy bằng cách không ràng buộc cơ chế điều phối của nó với cổng 80 cho đến khi có điều gì đó chủ động yêu cầu điều đó. (Đây là lý do tại sao ban đầu bạn sẽ gặp phải sự cố, nhưng có thể gặp phải sự cố này sau một số thay đổi cập nhật hoặc thay đổi cấu hình.) cố gắng lắng nghe dưới cổng 80 trước khi máy chủ ứng dụng của bạn khởi chạy. (Có nhiều lý do khác nhau mà một quy trình có thể cố gắng đăng ký một số URL nhất định trên cổng 80 và lùi lại nếu không được phép.)

Vì vậy, nếu bạn muốn một dịch vụ có quyền truy cập độc quyền vào cổng 80, tốt hơn bạn nên nói với Windows. Nó không thực sự đủ tốt để cố gắng tắt tất cả các dịch vụ có thể cố gắng sử dụng cơ chế chia sẻ cổng thông thường, bởi vì thật khó để tự tin rằng bạn đã tìm thấy tất cả chúng. . có thể cho những người bạn không biết về chuyến đi của bạn.

Theo mặc định HTTP.SYS(cơ chế chia sẻ cổng HTTP cơ bản trong Windows) có thể nghe trên tất cả các địa chỉ. Nhưng bạn có thể nói nó không phải. Trang này hiển thị một cách để làm điều đó: http://www.mikeplate.com/2011/11/06/stop-http-sys-from-listening-on-port-80-in-windows/

Đó là một cách tương đối nhẹ để làm điều đó, bởi vì nó vẫn cho phép nghe trên localhost cho IPv6. Nó chỉ giải phóng cổng IPv4 80. Bạn có thể đưa nó đi xa hơn với cấu hình chuyên dụng hơn. (Bạn thậm chí có thể vô hiệu hóa HTTP.SYShoàn toàn, nhưng điều đó có thể phá vỡ mọi thứ bằng cách sử dụng các cổng khác ngoài 80, vì vậy nó có thể gây ra sự cố.)

Nhưng bất cứ điều gì bạn làm, vấn đề là đảm bảo rằng HTTP.SYSkhông cố gắng lắng nghe cổng 80 trên địa chỉ IP mà bạn quan tâm. Khi bạn đã thực hiện điều đó, bạn không cần phải lo lắng về việc vô hiệu hóa các dịch vụ, bạn cũng không cần phải lo lắng về các thay đổi khác khi giới thiệu lại vấn đề. Nếu bạn đã đảm bảo rằng điểm cuối bạn cần thực sự nằm ngoài giới hạn cho việc chia sẻ cổng, thì bạn sẽ thấy rằng quy trình hệ thống dừng liên kết với nó.

Thủ phạm là dịch vụ đại lý triển khai web.

Giải pháp tốt hơn net stop httplà dừng các dịch vụ có tên "Dịch vụ đại lý triển khai web".

Rất có thể IIS 6.0 trở lên.

Ngăn xếp giao thức HTTP (HTTP.sys), chạy trong chế độ kernel , nhận các yêu cầu của máy khách và định tuyến chúng đến hàng đợi yêu cầu thích hợp. Các quy trình công nhân chạy trong chế độ người dùng, lấy các yêu cầu trực tiếp từ hàng đợi yêu cầu kernel của riêng họ, loại bỏ các bước xử lý xảy ra trong IIS 5.0 (và điều đó cũng xảy ra trong chế độ cách ly IIS 5.0) khi máy chủ Web gửi yêu cầu lên Cao -isolation, ứng dụng ngoài quy trình. Vì các bước nhảy quá trình bổ sung này được loại bỏ trong chế độ cách ly quy trình công nhân, IIS có thể cung cấp cách ly ứng dụng mà không làm giảm hiệu suất.

Hãy thử dừng HTTP.SYSbằng cách đi vào Device Manager/Non Plug and Play Driversvà Chọn HTTP, cố gắng dừng nó và bạn sẽ thấy các dịch vụ đang kích hoạt HTTP này để sử dụng cổng 80.

Tôi đã kiểm tra lần cuối, bạn không thể kết thúc quá trình "hệ thống" và nếu bạn làm vậy, tôi đoán nó sẽ có những hậu quả thảm khốc. Tôi sẽ không thử nó trên PC Tôi cũng đang ở ngay bây giờ!

Có vẻ như một cái gì đó bên trong Windows đang lắng nghe: 80 - Tôi sẽ đoán rằng nó có thể là một thứ gì đó độc hại. Cách tốt nhất để tìm hiểu là:

a) Mở trình duyệt web đến localhost và xem những gì sẽ xuất hiện

b) Khởi động Telnet và telnet đến localhost 80 và chạy một số HTTP GET cơ bản (ví dụ GET /) và xem những gì nó trả về

B là lựa chọn tốt hơn nếu bạn nghĩ rằng bạn có thể đang lưu trữ phần mềm độc hại, vì bạn không thực sự muốn lây nhiễm lại cho mình. Mặc dù có lẽ nó không thành vấn đề.

Tôi đã tìm thấy câu trả lời cho câu hỏi này tại: /superuser/352017/pid4-USE-port-80

Cụ thể khi đó là System Process 4, bạn cần phải tắt trình điều khiển HTTP.sys được khởi động theo yêu cầu bởi một dịch vụ khác, chẳng hạn như Windows Remote Management hoặc Print Spooler trên Windows 7 hoặc 2008.

1. Chuyển đến trình quản lý thiết bị, chọn các chương trình ẩn hiển thị các thiết bị ẩn, từ menu / chế độ xem, vào phần Non-Plug và chơi Driver Driver / HTTP, nhấp đúp vào nó để tắt nó (hoặc đặt thành thủ công, một số dịch vụ phụ thuộc vào nó).

Khởi động lại và sử dụng netstat -nao | tìm kiếm: 80 ″ để kiểm tra xem 80 có còn được sử dụng không.

Tôi cũng đã cố gắng lấy lại cổng bằng cách chạy "net stop http" nhưng cổng dường như không bao giờ được giải phóng. Ở trên đã làm việc cho tôi và II không cần các dịch vụ khác phụ thuộc vào trình điều khiển này.

Windows Sync Share là thứ đã giết chúng tôi trên Windows 2012 R2. Khi chúng tôi vô hiệu hóa tính năng này, mọi thứ đều ổn.

Trong trường hợp của tôi, đó là do vi-rút Carbon Black bằng cách nào đó đã siết cổ ở cổng 80. Tôi đã dành hàng giờ để cố gắng tìm ra nó, vì vậy tôi cảm thấy bắt buộc phải chia sẻ chỉ trong trường hợp nó dẫn một linh hồn tội nghiệp ra ánh sáng :) Tôi không Không biết chính xác nó đã được sửa như thế nào, hãy hỏi nhóm máy chủ / mạng của bạn!

Tôi đã giải quyết điều này thông qua một câu hỏi stackoverflow. Theo liên kết này để tìm giải pháp làm thế nào để IIS ngừng nghe trên cổng 80 cho một địa chỉ IP được chỉ định.