비전공자의 전공자 따라잡기 - 네트워크, HTTP

직접 서버 실행해보기 + 3XX 상태 코드

실습 node.js 서버 실행

https://github.com/zerocho/cs-network-http

300번대 상태코드 - Redirection messages

300(Multiple Choices) : 애매할 때 응답이 오는 것이다.
둘 중에 무엇을 응답해야할지 모를 때 사용한다. (요청을 애매하게 보내면 300)

301(Moved Permanently) or 302(Found) : 어떤 사이트에 접속을 했는데 다른 페이지로 접속을 하게 만들고 싶을 때 사용한다.
서버에서 Redirect 처리를 해놨을 때, 브라우저가 알아서 그 페이지로 옮겨간다.
영구적으로 페이지를 옮기고 싶을 때는 301을 쓴다.
302는 잠깐 페이지를 바꾸고 싶을 때(임시로 사용을 하게 하고 싶을 때) 사용하면 된다.
307(Temporary Redirect)은 302와 의미는 같지만, 강제사항으로 HTTP메서드를 변경하면 안된다.
(get이였다면 get으로)

304(Not Modified) : 나중에 캐시 강의에서 설명!

에러 상태 코드(4XX, 5XX)

400번대 상태코드 - Client error responses

깨알…

403을 잘 안쓰는 이유는 해커로부터 관심을 끄기 위한 위장을 해야한다.
404로 위장

500번대 상태코드 - Server error responses

그 뒤는 컨텐츠 협상이라고 보면 되는데 비어있는 숫자는 우리가 임의대로 만들어서 상황에 맞게 사용하면 된다.
꼭 이 코드들을 따르지 않아도 되지만 꼭 따라야 할 경우가 있다.
브라우저가 상태코드를 보고 강제로 작업하는 상태코드도 있기때문에 따라쓰는 것이 좋다.
애매하다면 대표적인 상태코드를 쓰기!

컨텐츠 협상과 MIME Type

HTTP(Hyper Text Transfer Protocol)의 구성

헤더와 본문(Body)으로 구성된다.
Text는 글자이지만 사실 이미지나 동영상 등 보낼 수 있지만 옛날 그대로 이어지는 것이다.
예전에는 본문을 가리키는 것을 content를 썼지만 현재는 payload라고 한다.
RFC최신버전을 잘 봐야 알 수 있다.

헤더 특징

예시 : GET / users HTTP / 1.1
헤더는 기본적으로는 키(Key)와 값(Value)으로 되어있다.
응답 헤더에서 키와 값1; 값2 or 값1, 값2로 구성되어있는 경우도 있다.
헤더는 한글이 안 된다. 인코딩을 해주지 않으면 에러가 난다.
에러 : cookie : name = ‘데브나비’

변환하는 방법 : encodeURIComponent(‘한글’)

컨텐츠 협상

요청 헤더에서 컨텐츠 협상(Accept) : 클라이언트가 어떤 데이터를 원하는지 서버에게 알려주는 것이다.
(내가 어떠한 컨텐츠를 원하는데, 어떤 형식의 데이터를 원하는지 알려주는 것)

Accept에서 q : 우선순위다. 내가 선호하는 우선순위를 정할 수 있다.
0~9까지 정할 수 있는데 html을 우선순위로 받겠다고 한다면 0.9로 높게 정할 수 있고, 그 뒤의 순위를 0.8, 0.7 …로 정한다.

Accept-Language : 어떤 언어로 할지를 정하는 것이다.
한글을 원한다면 ko-KR이다.
q로 우선순위를 정해주고 한글이 없다면 영어로 받기를 원한다고 정해준다.
언어코드는 ‘ISO Language Code Table’을 검색해서 찾으면 된다.

Accept-Encoding : HTTP설계가 Text다 보니까 헤더랑 바디가 text라서 용량이 너무 크다. 데이터 비용이 들기때문에 압축을 해서 받을 수 있다고 알려주는 것이다.

서버 주도협상 - (Accept 방식)

서버가 무조건 클라이언트가 원하는대로 보낼 수는 없지만, 선택은 서버가 하기때문에 서버 주도협상이라고 한다.

클라이언트 주도 협상

클라이언트 주도협상은 잘 하지 않는다고 한다. 요청을 2번 해야되기 때문이다.
클라이언트가 어떤 데이터가 필요하다고 한다.
서버가 여러 선택지를 보내주면, 클라이언트쪽에 어떤 형식의 데이터를 원하는지 응답을 해주게 된다.
클라이언트는 선택한 후, 다시 요청을 하게 된다.

컨텐츠 협상 이해하기 - 요청과 응답

Accept-Charset : utf-8, ascii, euc-kr
문자열을 어떤 방식으로 인코딩을 해서 줄지 정하는 것이다.

Accept-Language : ko, en
Accept-Encoding : gzip, br
Accept-Charset : utf-8, ascii, euc-kr

이렇게 요청을 보내면

서버에서는
클라이언트가 원하는 것 중 이렇게 선택해서 보내줬다고 응답이 온다.

Content-Type : text/html; Charset : “utf-8”
Content-Language : ko
Content-Encoding : br
이렇게 응답을 해주는 것이다.

하나 추가하자면, Content-Length : 2357(byte)는 실제 데이터 길이다.
2.3킬로바이트(KB)

MIME Type

대분류/확장자로 구성되어있다. 예시 : image/ png, image/jpeg 등

Keep-Alive, Date, Transfer-Encoding

Keep-Alive

요청헤더에 있는 Connection : keep-alive는
HTTP 1.0 예전 버전을 위해 존재하는 것이다. 1.1에서는 이것이 기본값이다.

응답헤더에는 Keep-Alive : tomeout=5 (기본값)
라고 되어있을텐데 tomeout=5라면 5초동안이다.
HTTP요청에서 더 나아가서 TCP요청에 3 way handshake가 일어나고 응답이 오고,
또 확인하고 응답이 오고 시간이 걸리게 된다.
이것을 한 번에 연결하는 것이 Connection : keep-alive다.
한번만 맺으면 앞으로도 재사용하여 데이터를 더 효율적으로 보낼 수 있게 한다. 기본값이 5초면 5초 후에 요청이 없다면 끊어버리고,
5초 후에 또 요청이 있다면 3 way handshake에서 열렸던 요청을 재사용한다.

Date

Date는 서버에서 응답 헤더 + 응답 바디가 생성된 시간이다. 서버시간을 알려준다. 내 컴퓨터의 시간과 상대방 서버시간이랑 다를 수가 있다.
컴퓨터는 과거로 시간을 바꿀 수도 있다.
Date를 보면 내 컴퓨터와 어느정도 시간이 차이가 나는지를 알 수 있다.
네트워크 시간에 따라 달라질 수 있어서 정확한 시간은 아닐 수도 있다.
예를들어, Date 시간에서 20초에 생성이 됐다고 표시가 나왔다.
실제 응답한 시간은 네트워크가 더 느릴 경우에 22초에 응답이 올 수 있다.

Transfer-Encoding

Transfer-Encoding : chunked
Content-Encoding : br

기본적으로는 서버가 응답을 보낼 때 데이터를 한 번에 다 보내준다.
가끔씩 Transfer-Encoding : chunked가 있다면 데이터를 쪼개서 보내준다.
Content-Encoding : br과 둘 다 있다면

HTTP/1.1 200 OK
“Hello world, Devnabi!”을 바디로 보내줄 때,
“Hello world, Devnabi!”가 인코딩이 되면
“Hello%20world%2C%20Devnabi%21”로 알아볼 수 없게 바뀐다.
이것을 chunked 한다라고 하면 인코딩됐던 것이 5개, 8개, 7개 이런식으로 잘려서 올 수 있다.
한 번에 보내기에는 너무 많기 때문에 잘라서 보내주는 것이다.

sec

sec가 앞에 붙은 헤더들은 특별한(?)것이라고 한다. MDN - HTTP header 찾아보기!

Authorization, 기타 헤더, 커스텀 헤더

Authorization

Authorization : Basic
Authorization : Bearer (토큰/실제값)
Authorization : Digest

여기서 Basic은 거의 본 적이 없고 Bearer, Digest를 많이 쓴다고 한다.
이 3개가 서버에서 어떻게 응답을 보내달라는 것인지 형식을 알려주는 키워드라고 보면 된다. 토큰을 붙여서 인증을 하는 것이다.

기타 예시 - 주의할 것

요청 : Post / Users HTTP/1.1
응답 : HTTP 1.1 405 Method Not Allowed
Allow : Delete (가능한 메서드를 알려주는 것은 필수다.)

Delete메서드를 써야하는데 실수로 post로 요청을 보냈다.
405 상태코드로 응답이 온다.
405는 필수로 Allow헤더를 써서 어떤 메서드가 되는지 알려줘야 한다.

헤더, 상태코드 공부 방법

공부할 때는 어떤 상태코드가 어떤 헤더와 연관되어있는지 같이 보는 것이 도움된다.
문제가 되지 않게 필수적인 것들을 확인!

기타 헤더

referer : 이전페이지가 어딘지 알려주는 것이다.
MDN에서 referer를 찾아서 들어갔다면 네트워크 탭 » referer에서 이전 페이지의 경로를 볼 수 있다.

이전 페이지를 알 수 있다는 것은 유입경로가 어딘지 알 수 있다는 것이고 마케팅이나 성과 측정에 쓰였다.
요즘은 개인정보 이슈가 있어서 Referrer Policy라는 것이 정해져 있다.
헤더를 보면 Referer이라고 되어있지만 이것은 스펠링이 틀렸다.
RFC 스펙을 만든 사람이 스펠링을 잘 몰랐기때문에 지금까지 이어진 것이라고 볼 수 있다. 헷갈림 주의

content-security-policy : 정책이다. 개인정보 이슈때문에 현재 사이트에 대한 정보나 개인정보를 가져가는 것을 제한하는 것이고 계속 발전하고 있다.

커스텀 헤더

문서에 나오지 않는 헤더, 잘 모르겠는 헤더들은 임의로 만든 헤더이고 커스텀 헤더라고 보면 된다.
다른 사이트에 넣어둔 헤더일 가능성이 있다. 어떠한 이유로 넣어둔 것이다. 의미를 몰라도 된다.
이미 있는 헤더라는 것을 알고 그 헤더 값을 바꾸는 것은 문제가 없지만
만약, 어떤 헤더가 이미 존재하고 있는지 몰라서 그 헤더의 이름을 사용하면 그대로 덮어씌어지기 때문에 문제가 된다.

Date : (서버시간)으로 이미 존재하고 있지만
Hello : world » Date : world가 되어버린다.
그래서 직접 만든 헤더들은 X-를 앞에 붙이는 것으로 약속을 했다.
기존 헤더들하고 겹칠일이 없기때문에 좋다. 약속을 지키자!