2012-02-10 24 views
7

Cho phép nói rằng tôi muốn GET một byte từ máy chủ bằng giao thức http và tôi muốn thu nhỏ mọi thứ, không có tiêu đề chỉ http://myserver.com/b trong đó b là tệp văn bản có một ký tự trong đó , hoặc tốt hơn vẫn b chỉ là một ký tự (không chắc chắn nếu điều đó là có thể). Có cách nào để làm điều này với apache và số lượng dữ liệu nhỏ nhất có thể được yêu cầu cho http hoàn chỉnh và, hoàn thành giao dịch https là gì? Ngoài ra, giao dịch có thể được thực hiện chỉ với yêu cầu đầu nếu đó là dữ liệu hiệu quả hơn.Yêu cầu dữ liệu http và https nhỏ nhất có thể là

+0

Bạn không thể thực hiện yêu cầu HTTP mà không có tiêu đề. –

+0

nếu tôi chỉ thực hiện yêu cầu HEAD, số lượng dữ liệu nhỏ nhất là bao nhiêu, tôi có thể giảm số lượng tiêu đề ở phía máy chủ xuống mức tối thiểu, tức là dữ liệu của tôi không? – alphablender

+0

@Chris, có bạn có thể. Theo [spec] (http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html), 'Dòng yêu cầu' (ví dụ:' GET/') không đúng tiêu đề. –

Trả lời

4

Chính xác những gì bạn đang cố gắng đạt được, đây có phải là một loại tiếp tục sống không?

Bạn có thể thực hiện "GET /", ngụ ý HTTP/1.0 đang được sử dụng, nhưng điều đó khóa bạn ra khỏi các nội dung như lưu trữ ảo v.v. Bạn có thể ánh xạ "/" tới tập lệnh cgi, không cần là một tệp thực sự, tùy thuộc vào những gì bạn đang cố gắng đạt được. Bạn có thể cấu hình Apache để chỉ trả về bộ tiêu đề tối thiểu, về cơ bản là "Content-Type: text/plain" (hoặc loại khác, loại mime ngắn hơn, có thể là mimetype tùy chỉnh, ví dụ "Content-Type: a/b") và " Độ dài nội dung: 0 ", do đó không trả về nội dung phản hồi.

+0

Tôi muốn kiểm tra một byte cho các bit cờ trong nybble thấp nhất, với 3 triệu người dùng, tôi muốn giữ cho việc truyền dữ liệu đến mức thấp nhất có thể. – alphablender

+5

@alphablender có thể bạn nên sử dụng một cái gì đó khác với HTTP sau đó. Bạn có thể dễ dàng viết một giao thức TCP trông như thế này: (1) khách hàng kết nối, (2) ngay lập tức gửi trọng tải tối thiểu của bạn, (3) ngắt kết nối. Đó là về như spartan như nó được. –

+1

Tôi đồng ý với Chris, nếu bạn triển khai máy chủ/giao thức của riêng mình, bạn có thể giữ lưu lượng dữ liệu ở mức tối thiểu. HTTP không phải là lựa chọn tốt nhất ở đây. –

4

Nếu bạn đang lập kế hoạch để sử dụng HTTP/1.1 (nhiều hơn hoặc ít hơn yêu cầu nếu bạn kết thúc trên một máy chủ ảo), yêu cầu GET bạn sẽ cần phải có tên máy chủ, hoặc trong Host tiêu đề hoặc như một URI tuyệt đối trong dòng yêu cầu (xem RFC 2616 section 5.1.2).

Câu trả lời của bạn cũng sẽ cần Content-Length hoặc transfer encoding headers and delimiters.

Nếu bạn sẵn sàng "ngắt" HTTP bằng cách sử dụng yêu cầu HEAD, có vẻ như HTTP có thể không phải là lựa chọn giao thức tốt nhất. Bạn cũng có thể trả về một cái gì đó trong một tiêu đề tùy chỉnh, nhưng đó không phải là cách làm sạch. Lưu ý rằng, ngay cả khi bạn thực hiện giao thức của riêng mình, bạn sẽ cần phải thực hiện một cơ chế tương tự như những gì Content-Length hoặc mã hóa chunked cung cấp, để có thể xác định thời điểm ngừng đọc từ bên từ xa (nếu không, bạn đã thắng ' t có thể phát hiện các kết nối bị đóng).

EDIT:

Dưới đây là một ví dụ nhanh, điều này sẽ thay đổi tùy theo tên máy chủ của bạn (giả sử HTTP 1.1). Tôi đoán bạn có thể sử dụng OPTIONS để thay thế. Nó phụ thuộc vào bao nhiêu bạn sẵn sàng để phá vỡ HTTP ...

Yêu cầu:

GET/HTTP/1.1 
Host: www.example.com 

Đó là 14 + 2 + 21 + 2 + 2 = 41 byte (2 cho CRLF)

phản ứng:

HTTP/1.1 200 OK 
Content-Length: 1 
Content-Type: text/plain 

a 

đó là 15 + 2 + 17 + 2 + 24 + 2 + 2 + 1 = 65 byte

Đối với HTTPS, sẽ b e một chi phí nhỏ cho chính kênh SSL/TLS, nhưng phần lớn nó sẽ được thực hiện bởi cái bắt tay, đặc biệt, chứng chỉ máy chủ (giả sử bạn không sử dụng xác thực client-cert) phải là lớn nhất. Kiểm tra kích thước (theo định dạng DER) của chứng chỉ của bạn.

+0

Ok vậy có ai biết số byte thực tế nhỏ nhất có thể được chuyển có thể sử dụng giao thức http và tương tự như vậy với giao thức https không? là nó thực sự 30 như một người nào đó được đề cập, hoặc là nó lớn hơn/nhỏ hơn /? – alphablender

0

Đây là một câu hỏi cũ, nhưng có thể ai đó thấy nó hữu ích, bởi vì không ai trả lời phần HTTPS của câu hỏi.

Đối với tôi điều này là cần thiết để xác thực dễ dàng giao tiếp HTTPS trong proxy của tôi, kết nối các proxy khác không đáng tin cậy thông qua đường hầm.

trang web này giải thích rõ ràng: http://netsekure.org/2010/03/tls-overhead/

Quotes từ bài viết:

Một điều cần ghi nhớ rằng sẽ ảnh hưởng đến tính là kích thước biến của hầu hết các tin nhắn. Bản chất biến sẽ không cho phép tính toán một giá trị chính xác, nhưng lấy một số giá trị trung bình hợp lý cho các trường biến, người ta có thể nhận được một xấp xỉ tốt của chi phí. Bây giờ, hãy xem qua từng thông điệp và xem xét kích thước của chúng.

  • ClientHello - kích thước trung bình của khách hàng ban đầu là khoảng 160 đến 170 byte. Nó sẽ thay đổi dựa trên số lượng ciphersuites được gửi bởi máy khách cũng như có bao nhiêu phần mở rộng TLS ClientHello. Nếu sử dụng nối lại phiên, cần thêm 32 byte khác cho trường ID phiên.
  • ServerHello - thông báo này tĩnh hơn một chút so với ClientHello, nhưng vẫn có kích thước biến do các phần mở rộng TLS. Kích thước trung bình là 70 đến 75 byte. -Giấy chứng nhận - thư này là thông báo thay đổi nhiều nhất về kích thước giữa các máy chủ khác nhau. Thông báo mang chứng chỉ của máy chủ, cũng như tất cả các chứng chỉ của tổ chức phát hành trung gian trong chuỗi chứng chỉ (trừ chứng chỉ gốc). Vì kích thước chứng chỉ thay đổi khá nhiều dựa trên các thông số và khóa được sử dụng, tôi sẽ sử dụng mức trung bình 1500 byte cho mỗi chứng chỉ (chứng chỉ tự ký có thể nhỏ tới 800 byte). Các yếu tố khác nhau khác là độ dài của chuỗi chứng chỉ lên đến chứng chỉ gốc. Để có mặt thận trọng hơn về những gì có trên web, hãy giả sử 4 chứng chỉ trong chuỗi. Nhìn chung, điều này cho chúng ta khoảng 6k cho thông điệp này.
  • ClientKeyExchange - giả sử một lần nữa trường hợp được sử dụng rộng rãi nhất - chứng chỉ máy chủ RSA. Điều này tương ứng với kích thước 130 byte cho thông báo này.
  • ChangeCipherSpec - kích thước cố định 1 (về mặt kỹ thuật không phải là thông báo bắt tay)
  • Hoàn thành - tùy thuộc SSLv3 được sử dụng hay TLS, kích thước thay đổi tương ứng một chút - 36 và 12 byte. Hầu hết các trường những ngày này hỗ trợ TLSv1.0 ít nhất, vì vậy chúng ta hãy giả TLS sẽ được sử dụng và do đó kích thước sẽ là 12 byte

Vì vậy, tối thiểu có thể lên lớn (hoặc nhỏ) như:

20 + 28 + 170 + 75 + 800 + 130 + 2*1 + 2*12 ≈ 1249 

Mặc dù theo bài viết, mức trung bình là khoảng 6449 byte.

Ngoài ra, điều quan trọng là phải biết rằng các phiên TLS có thể được tiếp tục, vì vậy chỉ kết nối thứ nhất có phí trên này. Tất cả các tin nhắn khác có khoảng 330 byte cộng.

Các vấn đề liên quan