나는 TCP를 통해 내 자신의 목적을 위해 프로토콜을 쓰는 것을 일반적으로 고려하고 있었고 메시지의 끝을 결정하는 문제에 부딪혔다.Content-length는 HTTP 메시지가 완전히 수신 된 것을 알 수있는 유일한 방법입니까?
HTTP에서 파생 된 메시지 길이는 Content-length에 언급되어 있으며 메시지가 완전히 수신되었다고 판단 할 수있는 방법입니다. 그게 유일한 방법인가요? AFAIK 헤더가 HTTP 메시지에서 선택 사항이므로이 헤더가없는 경우 어떻게됩니까?
감사합니다.
이것이 유일한 방법입니까?
다른 방법이 있습니다.
끝 (그리고 아마도 다음 메시지의 시작)을 구분 기호로 표시하십시오. 예 : 모든 메시지를 개행 문자로 끝낼 수 있습니다. 그래서 메시지를 읽으려면, 개행 문자까지 모두 읽으십시오. 이 경우 메시지 내용에 개행 자체가 포함되지 않도록해야합니다 (예 : 읽는 동안 보내고 도망 칠 때 메시지의 줄 바꿈을 이스케이프 처리합니다. 또는 개행 문자 (예 : base64 또는 ascii-hex)가 포함되지 않은 인코딩으로 메시지를 인코딩하십시오.
파서가 암시 적으로 메시지의 시작과 끝을 감지하는 구조를 포함하도록 메시지의 서식을 지정하십시오. 예 : json을 보내면 데이터를받을 때 json을 구문 분석해야하고 { 및 [ 문자가 모두 일치하면 메시지가 나타납니다.
각 메시지 앞에 길이를 붙입니다. 이것은 HTTP의 "Content-Length"와 매우 비슷하지만 길이를 2 진수로 인코딩합니다 (예 : 각 메시지의 처음 4 바이트는 뒤 따르는 데이터의 길이를 보유합니다. 이 헤더가없는 경우 AFAIK 헤더가 HTTP 메시지의 선택이기 때문에, 무슨 일이 일어날 지
.
많은 문제가 있기 때문에 더 까다 롭습니다.
HTTP/1.0의 경우 실제로 몸체가 있으면 요청에 Content-Length가 있어야합니다. HTTP/1.1의 경우 요청은 메시지 본문에서 길이를 파싱 할 수있는 특정 콘텐츠 인코딩 (예 : 청크 인코딩)을 포함 할 수 있습니다.
http 응답의 경우 메시지의 끝은 연결을 닫음으로써 나타낼 수 있으며 헤더 끝에서부터 스트림 끝까지의 모든 것을 "메시지"로 간주합니다. 좀 더 정보 here
. 대단한 답장. – euphoria83
메시지가 완료된 곳을 알 수있는 다른 방법 - 보내기 후 닫기 소켓). 그러나 콘텐츠 길이와 같은 것을 사용하는 것이 좋습니다.
내가 직접 http-server를 쓸 때 : content-length가없는 모든 http post 패킷을 닫는 절차를 작성합니다.
HTTP : //tech.hickorywind.org/articles/2008/05/23/content-length-mostly-do-not-matter-the-reverse-bob-barker-rule 서버는 무언가가 다운로드를 마쳤을 때의 궁극적 인 결정자이기 때문에 Content- 길이를 너무 높게 설정하면 스트리밍 할 비트가 부족하면 서버에서 파일 스트리밍을 중지합니다. –
하나의 HTTP 메시지가 전송 된 후 연결이 종료되어야한다고 가정합니다. HTTP 1.1을 사용하면 여러 메시지를 보낼 수 있습니다. 감사합니다. – euphoria83