[HTTP/네트워크] 211018 HTTP/네트워크 기초 및 추가공부(2)

📌 HTTP

HTTP는 웹에서 브라우저와 서버가 통신하기 위한 프로토콜(규약)이다. HTTP는 요청 메서드를 정의하여, 주어진 리소스에 수행하길 원하는 행동을 나뉜다. 간혹 요청 메서드를 "HTTP 동사"라고 부르기도 한다.

• GET
  GET 메서드는 특정 리소스의 표시를 요청. GET을 사용하는 요청은 오직 데이터를 받기만 한다.
• HEAD
  HEAD 메서드는 GET 메서드의 요청과 동일한 응답을 요구하지만, 응답 본문(body)을 포함하지 않는다.
• POST
  POST 메서드는 특정 리소스에 엔티티를 제출할 때 쓰인다. 이는 종종 서버의 상태의 변화나 부작용을 일으킬수있다.
• PUT
  PUT 메서드는 목적 리소스 모든 현재 표시를 요청 payload로 바꾼다.
• DELETE
  DELETE 메서드는 특정 리소스를 삭제.
• CONNECT
  CONNECT 메서드는 목적 리소스로 식별되는 서버로의 터널을 맺는다.
• OPTIONS
  OPTIONS 메서드는 목적 리소스의 통신을 설정하는 데 쓰인다.
• TRACE (en-US)
  TRACE 메서드는 목적 리소스의 경로를 따라 메시지 loop-back 테스트를 한다.
• PATCH
  PATCH 메서드는 리소스의 부분만을 수정하는 데 쓰인다.
  - HTTP 요청메소드 MDN 참고 -

☑ HTTP/1.1

HTTP1.1은 기본적으로 커넥션 당 하나의 요청과 응답만 처리. 여러개의 요청을 한번에 전송할 수 없고 응답 또한 마찬가지이다. 그래서 요청할 리소스의 개수에 비례하여 응답시간도 증가한다.

☑ HTTP/2

커넥션당 여러개의 요청과 응답, 즉 다중 요청 응답이 가능하다. HTTP/1.1에 비해 페이지 로드 속도가 약 50프로 정도 빠르다고 한다.

📌 HTTP 메시지

HTTP 메시지는 서버와 클라이언트 간에 데이터가 교환되는 방식. 메시지 타입엔 두가지가 있다. 바로 요청(request)과 응답(response)이다. 이 방식들의 구조는 서로 닮았다.

1. 시작 줄(start-line)에는 실행되어야 할 요청, 또은 요청 수행에 대한 성공 또는 실패가 기록되어 있다. 이 줄은 항상 한 줄로 끝난다.
2. 옵션으로 HTTP 헤더 세트가 들어간다. 여기에는 요청에 대한 설명, 혹은 메시지 본문에 대한 설명이 들어간다.
3. 요청에 대한 모든 메타 정보가 전송되었음을 알리는 빈 줄(blank line)이 삽입.
4. 요청과 관련된 내용(HTML 폼 콘텐츠 등)이 옵션으로 들어가거나, 응답과 관련된 문서(document)가 들어간다. 본문의 존재 유무 및 크기는 첫 줄과 HTTP 헤더에 명시.

📌 HTTP 요청

1) 시작줄(start line)
HTTP 메서드 URL, 또는 프로토콜, 포트, 도메인의 절대 경로(슬래쉬는 전체페이지를 가리킨다) HTTP 버전

2) 헤더

• General 헤더: Via와 같은 헤더는 메시지 전체에 적용.
• Request 헤더: User-Agent (en-US), Accept-Type와 같은 헤더는 요청의 내용을 좀 더 구체화 시키고(Accept-Language), 컨텍스를 제공하기도 하며(Referer), 조건에 따른 제약 사항을 가하기도 하면서(If-None) 요청 내용을 수정.
• Entity 헤더: Content-Length와 같은 헤더는 요청 본문에 적용. 당연히 요청 내에 본문이 없는 경우 entity 헤더는 전송되지 않는다.

3) 본문
모든 요청에 본문이 들어가지는 않는다. GET, HEAD, DELETE,OPTIONS처럼 리소스를 가져오는 요청은 보통 본문이 필요가 없다. 일부 요청은 업데이트를 하기 위해 서버에 데이터를 전송. 보통 (HTML 폼 데이터를 포함하는) POST 요청일 경우에 그렇다.

📌 HTTP 응답

1) 상태줄(status line)
프로토콜 버전 상태코드( 200, 404 혹은 302) 상태 텍스트

2) 헤더

• General 헤더: Via와 같은 헤더는 메시지 전체에 적용.
• Response 헤더: Vary와 Accept-Ranges와 같은 헤더는 상태 줄에 미처 들어가지 못했던 서버에 대한 추가 정보를 제공.
• Entity 헤더: Content-Length와 같은 헤더는 요청 본문에 적용된다. 당연히 요청 내에 본문이 없는 경우 entity 헤더는 전송되지 않는다.

3) 본문
본문은 응답의 마지막 부분에 들어간다. 모든 응답에 본문이 들어가지는 않는다. 201, 204과 같은 상태 코드를 가진 응답에는 보통 본문이 없다.

넓게 보면 본문은 세가지 종류로 나뉨.

• 이미 길이가 알려진 단일 파일로 구성된 단일-리소스 본문: 헤더 두개(Content-Type와 Content-Length)로 정의 한다.
• 길이를 모르는 단일 파일로 구성된 단일-리소스 본문: Transfer-Encoding가 chunked로 설정되어 있으며, 파일은 청크로 나뉘어 인코딩 되어 있다.
• 서로 다른 정보를 담고 있는 멀티파트로 이루어진 다중 리소스 본문: 이 경우는 상대적으로 위의 두 경우에 비해 보기 힘듬.

📌 HTTP 상태코드

상태코드가 너무 많아서 이 부분은 MDN링크로 대체하고자 한다. 자주 본 것들 또는 익숙한 것들만 여기에 적었다. 대충 몇번대가 어떤 걸 의미하는지는 알아야 한다고 해서 아래 그림을 참고한다.

• 200 OK
  요청이 성공적으로 되었습니다. 성공의 의미는 HTTP 메소드에 따라 달라짐:
  GET: 리소스를 불러와서 메시지 바디에 전송.
  HEAD: 개체 해더가 메시지 바디에 있음.
  PUT 또는 POST: 수행 결과에 대한 리소스가 메시지 바디에 전송.
  TRACE: 메시지 바디는 서버에서 수신한 요청 메시지를 포함.

• 404 Not Found
  서버는 요청받은 리소스를 찾을 수 없음. 브라우저에서는 알려지지 않은 URL을 의미. 이것은 API에서 종점은 적절하지만 리소스 자체는 존재하지 않음을 의미할 수도 있음. 서버들은 인증받지 않은 클라이언트로부터 리소스를 숨기기 위하여 이 응답을 403 대신에 전송할 수도 있다.(로그인하지 않은 상태에서 깃헙을 보려고 할때 자주 보았다;)

1xx : 잠깐만 기다려봐
2xx : 자,여기있어
3xx : 저리 가(반복된 요청)
4xx : 너(클라이언트)가 망침
5xx : 내(서버)가 망침

HTTP 상태코드 MDN

📌 HTTP 간단 체크포인트

클라이언트-서버 모델에 대한 설명 중 옳은 것?

• 웹 개발에서 클라이언트는 브라우저를 말합니다.
• 클라이언트는 서버에 요청을 보내고, 응답을 받는다.
• 서버는 데이터베이스에 요청을 보내고, 응답을 받는다.

80번 포트를 사용해 통신하는 대표 프로토콜

• HTTP

URL의 구성요소가 아닌 것?

• URL의 구성요소는 scheme, hosts, url-path. URI는 URL의 구성요소를 모두 포함하고, query, bookmark 등이 추가됨

HTTP 상태코드와 설명

• 200 : OK, 성공적으로 응답을 마침
• 302 : Found, 리다이렉트할 URL을 확인함
• 404 : Not Found, 클라이언트가 잘못된 페이지를 서버에 요청하여 페이지를 찾을 수 없음.
• 406 : Not Acceptable, 클라이언트가 응답 코드를 받을 수 없음
• 500 : Internal Server Error, 서버에서 에러가 발생함

클라이언트가 서버에 요청을 보내는 과정 중 일부

• AJAX는 Asynchronous JavaScript and XML 의 줄임말입니다.
• 브라우저의 주소창에 naver.com을 입력하면, naver의 서버에 get 요청을 보냅니다.
• fetch를 사용하여 서버의 응답을 확인하기 위해서는 .then을 사용해야 합니다.
• AJAX는 CSR(Client Side Rendering)을 위해 사용합니다.

CSR과 SSR에 대한 설명

• SEO가 가장 우선 순위인 경우, SSR을 사용합니다.
• 동적 상호작용이 많은 웹 애플리케이션에는 CSR이 적합합니다.
• CSR에서 서버는 주로 API 응답을 담당합니다.

HTTP Messages에 대한 설명

• 요청과 응답은 유사한 구조를 가지며, 요청의 첫 번째 줄은 Status line입니다.
• GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1 은 url에 새로운 정보를 입력합니다.

클라이언트와 서버의 역할

• 클라이언트: 서버로부터 받은 응답에 따라 다른 화면을 표시합니다.
• 클라이언트: 유저와의 전반적인 상호작용을 담당합니다.
• 서버: 클라이언트의 요청에 따라 적절한 응답을 되돌려 줍니다.

AJAX 설명

• AJAX를 통해 클라이언트는 필요한 데이터만 서버를 통해 비동기적으로 받고, 페이지의 일부만 동적으로 업데이트 할 수 있다.
• 비동기적인 웹앱 제작을 위한 웹 개발 기법이다.
• Fetch API를 통해 AJAX 요청을 보낼 수 있다.

CORS에 대한 설명

• 클라이언트와 서버가 서로 다른 origin에 있는 경우가 있으므로 CORS 기술이 도입되었다.
• 서버쪽에서 클라이언트를 대상으로 리소스의 허용 여부를 결정하는 방법이다.
• 같은 origin에서 fetch를 시도하면 CORS 문제가 발생하지 않는다.
  CORS 공식문서

origin(출처)이 다르다고 판단하는 경우

• 프로토콜
• 호스트(도메인)
• 포트번호

preflight request에 대한 설명

• 실질적인 요청 전, OPTIONS 메서드를 통해 발생한다.
• 실제 요청이 안전한지 서버가 미리 파악할 수 있도록 하는 수단이다.
• 모든 cross origin 요청이 preflight request를 발생시키는 것은 아니다.

크롬 브라우저의 에러 메시지에 대한 설명

• ERR_BAD_SSL_CLIENT_AUTH_CERT : 클라이언트 인증서(은행 또는 회사 내부 웹사이트 등)에 오류가 발생하여 웹페이지에 로그인할 수 없습니다.
• Aw, Snap! : Chrome 브라우저에서 페이지를 로드하는 데 문제가 발생했습니다.
• ERR_NAME_NOT_RESOLVED : 호스트 이름(웹 주소)이 존재하지 않습니다.

다음 URI를 보고 유추할 수 있는 설명

• 통신 프로토콜로 https를 사용하고 있기 때문에 port 번호는 443이다.
• 해당 URI는 scheme, hosts, url-path, query로 이루어져있다.
• URL은 URI라고 할 수 있지만, URI가 더 큰 개념이기 때문에 URI는 URL이라고 할 수 없다.
• url-path는 /search를 의미하고, 웹 서버에 전달하는 추가 질문은 query에 대한 설명이다.

HTTP 메서드에 대한 설명

• PUT 메서드는 요청 페이로드를 사용해 새로운 리소스를 생성하거나, 대상 리소스를 나타내는 데이터를 대체합니다.
• GET 메서드는 특정한 리소스를 가져오도록 요청합니다. GET 요청은 데이터를 가져올 때만 사용해야 합니다.
• 멱등성 메서드에는 통계 기록 등을 제외하면 어떠한 부수 효과(side effect)도 존재해서는 안됩니다. 올바르게 구현한 경우 GET, HEAD, PUT, DELETE 메서드는 멱등성을 가지며, POST 메서드는 그렇지 않습니다.
• DELETE 메서드는 지정한 리소스를 삭제합니다.

URI에 해당하는 port 번호

• imap://user:password@in.example.com의 port 번호는 143이다.
• ftp://jamesc@ftp.harlequin.com/foo.html의 port 번호는 21이다.
• HTTP는 80번 port, HTTPS는 443번 port를 사용.

HTTP에 대한 설명

• HTTP 요청의 종류에 따라서 달라집니다.
• 서버가 처리할 수 없는 요청의 경우 500번대 status code를 반환합니다.
• 클라이언트와 서버 간 요청-응답이 이루어지는 과정이다.
• 브라우저와 서버가 통신할 수 있도록 만들어 주는 여러 프로토콜 가운데 한 종류다.
• 서버는 클라이언트의 요청에 대해 무조건 응답을 돌려 주어야 한다.

AJAX에 대한 설명

• AJAX를 사용하면 Search Engine Optimization(SEO)에 불리합니다.
• AJAX를 구성하는 주요 기술은 Javascript, DOM, Fetch 등이있고, 이를 통해 CSR(Client Side Rendering)이 가능해졌습니다.
• AJAX를 사용하면 뒤로 가기 등의 기능을 구현하기 위해서 별도의 History API를 사용해야 한다.
• 표준화 된 XHR의 등장과 함께 브라우저에 상관 없이 AJAX를 사용할 수 있게 되었고, 지금은 XHR을 개선한 Fetch API를 사용하여 편리하게 AJAX를 구현할 수 있게 되었다.
• Fetch API를 사용하기 전에는 XMLHttpRequest 객체를 사용해 서버에서 데이터를 전송받아 처리하였습니다.
• AJAX는 Javascript, DOM, fetch 등의 다양한 기술의 집합이며, 풍성한 유저 경험을 위해서 사용됩니다.
• JSON이나 XML 형태로 필요한 데이터만을 받아 갱신하기 때문에 그만큼의 자원과 시간을 아낄 수 있습니다.

AJAX가 사용된 기능

• 구글 검색창의 추천 검색어
• 받는 사람 이메일 주소 작성 시, 이메일 주소 추천 기능
• 무한 스크롤 하면 계속해서 구인공고를 보여주는 원티드 웹사이트
• 네이버 포털사이트의 메인화면 속 뉴스탭

DNS설명

• DNS(Domain Name System)은 도메인 주소를 IP 주소로 변환하는 시스템 입니다.
• 도메인 주소는 가장 왼쪽부터 오른쪽으로 서브도메인(Sub Domain), 루트 도메인(Root Domain), 최상위 도메인(Top Level Domain)으로 구성되어 있습니다.
• 도메인 네임 서버 중 권한 있는 네임 서버는 IP 주소 및 도메인 정보를 관리하는 권한을 가진 서버입니다.
• 존 파일(zone file)은 네임과 클래스, TTL, 레코드 타입, 레코드 데이터로 구성되어 있으며, 도메인과 주소가 매핑된 일종의 테이블 이라고 볼 수 있습니다.

그 외

• 웹 애플리케이션의 클라이언트-서버 아키텍처에서, 웹 페이지와 node.js 프로그램은 각각 클라이언트와 서버를 담당한다.
• 데이터베이스 입장에서 데이터베이스를 사용하는 node.js 애플리케이션은 클라이언트라고 볼 수 있다.
• HTTP 프로토콜을 이용해 웹 서버에서 제공하는 API 호출을 할 수 있다.
• node.js 런타임에서 제공되는 모듈은 API이다.