c#으로 근본 없는 웹서버 개발기 4 : HTTP 헤더정보 살피기

⚠WARNING

ASP.NET에 대한 포스팅이 아닙니다
나가실 문은 오른쪽 하단입니다

 

 

웹사이트에서 없어도 되는부분이지만.
북마크나 즐겨찾기로 추가 했을 때, 제목보다 눈에 빨리 들어오는 것이 favicon.ico 일것이다. 사람의 뇌는 글보다 이미지에 대한 기억을 오래 간직한다. 그러므로 본인의 웹사이트에 대한 애정이 있다면 favicon에 신경을 쓸것이다. 
그리고 손님으로써 방문한 사이트에 favicon이 없다면 먼가 허전할 것이다.

그렇다.

favicon은 하나의 단순한 이지미가 아니라 사이트의 얼굴마담, 마스코트, 그리고 IdenTT 인것이다.

그래서 favicon을 기준으로 어떻게 브러우저부터 요청이 되는지 헤더값을 살표보기로 했다

---

요청헤더 살펴보기

request header by chrome

전 편에 이어서 알아야 할부분이, Connection: keep-alive 인데, 이게 있으면 요청 때 마다 소캣을 재연결 하는게 아니라 연결한 상태로 데이터를 주고 받는다고 한다. 한번에 서로 주고 받음이 많을 수록 유리하다고 한다.

https://goodgid.github.io/HTTP-Keep-Alive/

 

그리고 맨 아랫쪽 두줄은 파일의 유무성을 체크하기 위한 부분으로 If-None-Match는 서버에서 관리하는 파일의 고유번호같은 거고 If-Modified-Since는 이름 그대로 파일의 수정 시간인데, 후자는 시간이 겹칠 수 도 있으나 전자는 언제나 확실한 비교를 할 수 있으므로 두 개다 사용하는듯 하다. 만약 서버에도 똑같은 것이(w/"file-17...) 존재 할 경우 서버는 파일을 전송하지 않고 304를 응답하여, 브라우저가 가지고 있는 파일을 쓰도록 유도한다고 한다.

https://withbundo.blogspot.com/2017/07/http-13-http-iii-if-match-if-modified.html

[HTTP 프로토콜 강좌]#13 HTTP 요청 헤더 III - If-Match, If-Modified-Since, If-None-Match

트와이스를 좋아한다면 더 이해되기 쉽게 설명이 되어있다.

---

응답헤더 살펴보기

response by express

노드 EXPRESS서버가 위에서 설명한데로 favicon.ico가 이미 존재하므로 같은 Etag값을 보여주고 304를 보내 주었다.

당연한 소리지만 파일크기가 클 수록 매우 효율적이다.
두번 째 줄의 x-Powerd-by가 어떤 기술의 서버인지 힌트를 준다. (저것은 노출되지 않게 할 수 있다)

Accept-Ranges는 bytes 일 때 이어받기를 지원한다고 한다.

그리고 Etag의 경우는 W, S로 나뉜다고 하는데, 사이트마다 형식이 다른것을 보니, 자기 꼴리는 대로 하는거 같다.

중요한점은 중북되지 않게 하는것 인듯 하다.

https://withbundo.blogspot.com/2017/08/http-16-http-i-accept-range-etag.html

이 또 한 트와이스를 좋아하실거 같은분이 잘 정리해놓으셨다. (시간내서 정독해야 할듯하다.)

 

그리고 마지막으로 알아볼 부분이 응답헤더의 Cache-Control 인데,  중간에 캐시서버가 있을 경우 max-age 값이 유효하면 목적서버에 질의 하지 않고 캐시서버가 대신 데이터를 전송해 준다고한다. (트래픽을 줄이기 위한.)
사진에는 max-age가 0으로 되어 있는데, 이 경우에는 유효기간이 없으므로 무조건 목적 서버에 질의 하게 된다고 한다.

https://www.huskyhoochu.com/cache-control/

이 분것도 내용은 길지 않지만 잘 정리되어 있다.

 

그렇다

웹이라는 것의 중요한 부분만 대략 알아보려고 했으나 깊게 파면 알아야 할 부분이 상당하다.

つづく