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

네트워크 탭 사용하기

네트워크 탭 사용하기

요청과 응답을 볼 때는 네트워크 탭을 쓰는 것이 좋다.

캐시는 꺼두고 사용하기 : 캐시를 키는 것, 끄는 것에 따라 보여지는 것이 완전히 다르다.
정확한 요청을 보려면 캐시를 끄기!
속도 조절을 할 수 있다. (인터넷 느린 환경, 네트워크 안되는 환경 조절 가능)
헤더와 바디를 볼 수 있고 요청과 응답이 같이 기록되어있다.
요청은 헤더만 보낸 것이고 응답은 헤더와 바디를 응답한 것이다.
요청에 바디를 보냈다면 페이로드(Payload)라는 것이 떠야한다.
보내고자 하는 데이터 자체를 의미하며, 부가적인 것은 제외다.
일반적으로는 요청에 바디를 보내지 않는다.
크롬 탭은 보기편하게 되어있어서 잘 활용하자.
네트워크 탭은 프로토콜도 볼 수 있다.
브라우저는 응용 계층의 프로그램이기때문에 데이터링크 계층은 와이어샤크를 이용해서 볼 수 있다.

RFC 보는 방법

RFC 보는 방법

RFC JUNE 2023 Link! -> RFC 9394

네트워크 탭을 이용하여 헤더들을 볼 때, 각자의 역할이 궁금하고 모르는 것이 있다면 RFC 공식문서를 보면 된다.
RFC는 표준이고 헤더들에 대한 정의들이 나와있다.
계속 업데이트가 되기때문에 최신버전으로 보는 것이 좋다.
영어로 되어있어서 어렵다면 크롬 번역을 사용하여 볼 수 있다.
잘 찾아보면 문서를 번역한 것을 제공하는 블로그도 찾을 수 있고, 다운로드를 받아서 볼 수 있다.
특정 헤더가 궁금하다면 검색기능을 통해 빠르게 볼 수 있다. (최신인지 확인)
최신 것을 보고 싶다면 Obsoleted by를 클릭한다.
더이상 Obsoleted by가 없으면 가장 최신이다.

RFC 공식문서 더 쉽게 공부하는 방법

핵심 공부하기 Link! -> MDN - HTTP

공식문서가 딱딱하고 보기 힘들다면 MDN으로 봐도 좋다.
MDN에서 HTTP섹션을 들어가서 공부하면 된다.
MDN으로 핵심적인 내용을 공부하고 익숙해졌다면 RFC공식문서로 정확하게 공부를 하자.
네트워크 탭에서 헤더들을 볼 때는 와이어샤크랑은 달라서 헷갈릴 수 있다.
그럴 때는 View source를 보면 원문이 나와서 헷갈리지 않게 볼 수 있다. (원문으로 공부)

주소 구성 체계(URL, URI, Origin)

URL URI 차이?

URL: Uniform Resource Identifier
URI : Uniform Resource locator

Uniform Resource는 네트워크의 자원을 찾는 것을 의미한다.
Identifier인지 locator인지의 차이다.
예전에는 예시로 ‘https://devnabi.github.io/index.html’로 확장자를 붙여서 찾았었는데 요즘에는 가상으로 폴더를 찾는 느낌이다.
실제 자원을 가리키는 것이면 URL이라고 했지만 요즘에는 가상의 ID 역할을 쓴다고 하여 URI를 더 쓴다.
용어차이라서 너무 구분을 짓지 않아도 된다.

‘https://devnabi.github.io/index.html’이 URL,
‘https://devnabi.github.io/series/’가 URI라고 보면 된다.

URL의 구성요소

예시 : https: // user : pass @ sub.example.com : 8080 /p/a/t/h ? query=string #hash

@앞에 유저이름과 비밀번호를 넣는 부분이 있는데 인증을 위한 정보를 넣는 공간이다.
@뒤에는 host라고 부르고 다음은 포트, 경로, query=string, #은 hash다.
‘https://devnabi.github.io/series/’에서 ‘/series/’ 부분을 path(경로)라고 한다.
#태그는 프론트에서만 사용하고 유효하다. (서버에서는 인식 X)
혹시나 서버로 정보를 보내고 싶다면 query=string을 쓰면 된다.

프로토콜에서 host까지 Origin이라고 부른다.
이 전체를 ‘href’ 또는 URL이라고 한다.

헤더 한 번 훑고 가기

헤더 훑기

HTTP 0.9 시절에는 남의 네트워크로 정보를 받아올 수 있다는 생각을 하지 못했어서 host가 없고 자원의 표기만 했었다.
지금까지 그렇게 굳어져온 표기다.

Accept는 어떤 것을 표시한 걸까?

어떤 형식의 데이터를 원한다고 알려주는 것이다.

서버랑 어떤 데이터를 주고 받을지, 요청을 하며 헤더를 통해 알려준다.
예를들면 html이고 한글 형식이고 압축된 데이터 등 써져있다.
서버도 요청이 오면 데이터를 줄 준비를 하는데 요청에선 html을 원하고 서버가 준비한 데이터는 json데이터뿐이라면, html 데이터는 없다고 응답을 보낼 수 있도 있지만 json데이터로 응답을 하는 서버도 있다. 서버나름
네트워크 주고받고하는 것도 비용이다. 비용을 아끼기 위해서는 캐시를 잘 활용해야 한다.
예시로는 파일을 보관하는 비용보다 파일을 주고 받는 비용이 크다는 것을 생각하면 된다.

HTTP는 무상태(Stateless)다?

아무리 요청과 응답 헤더를 봐도 누가 요청을 보냈는지에 대해서는 나오지 않는다.
누가 로그인을 해도 뜨지 않는다. 즉, 서버는 이 요청이 누구에게서 온 것인지 모른다.
HTTP 요청을 연달아 받아도 어떤 요청이든 앞의 요청과 다음 요청은 영향이 가지 않는다.
앞 요청이 실패해도 다음 요청은 성공할 수 있다.
그래서 HTTP가 상태가 없다는 것이다.

쿠키(Cookie)?

로그인을 한다는 것은 나라는 것을 계속 유지시켜줘야 한다는 것인데 HTTP는 무상태기때문에 힘들다.
그래서 그것을 해결하려고 쿠키라는 것이 있고 각종 정보를 담아서 보내는 것이다.
직접적으로 정보를 알려주진 않지만 이상하고 긴 문자열을 담아서 서버가 처리하도록 보낸다.
서버에서 이 문자열로 데이터베이스나 메모리등으로 찾아서 누군가의 데이터라고 인식을 한다.
이렇게 HTTP는 무상태라서 요청 간에 영향이 가지 않는다.

user-Agent?

사용자가 어떤 환경이고 어떤 브라우저인지 확인을 해주는 것인데 유명무실하다.
차라리 다른 것으로 확인하는 것이 좋고 개인정보보호가 중요하기때문에 없어지는 추세다.

헤더가 자세한 것이 좋은 이유

개발자 입장에서는 헤더가 많고 자세하게 나와있는 것이 좋다. 디버깅할 때 쉽기때문이다.
헤더가 자세할 수록 정보가 많아서 오류가 뭐 때문에 났는지 확인하기 쉽다.
문제는 해커들도 좋아한다…

General

General은 요청과 응답헤더를 섞어서 중요한 것만 빼서 보여준다.
한 번에 보기 쉽도록 해놓은 것이다.