goal
- 클라이언트-서버 콘셉트를 이해한다.
- 브라우저의 작동 원리를 이해한다.
- Chrome Network Tab을 이해할 수 있다.
- HTTP messages의 구조를 설명한다.
같이보면 좋을 글 (중복포함)
이전에 작성한 나의 포스팅
- 웹 관련 지식 :) 웹의 동작방식(HTTP, TCP/IP, DNS) 큰 그림, 패킷의 얕은 이해
1. 클라이언트 - 서버 아키텍쳐
2티어 아키텍쳐, 3티어 아키텍쳐가 무엇인가?
나의 포스팅 자료참고
2. 브라우저의 작동 원리
[1] 클라이언트와 서버 간의 통신 방법
HTTP 1 프로토콜
- 웹 애플리케이션 아키텍처에서는 클라이언트와 서버가 HTTP 프로토콜로 대화를 나눈다.
- HTTP를 이용해 주고 받는 메시지는 "HTTP 메시지"라고 부른다.
1 프로토콜
프로토콜은 규칙이며, 프로토콜 이름에 따라 지원하는 것이 다르며 계층 위치도 다르다.
- 계층과 관련해서는 OSI 7계층을 공부하자
- OSI 7계층 관련한 : 웹 관련 지식 :) TCP / IP란? OSI 7계층과 TCP / IP 4계층, 내블로그
프로토콜의 동작계층과 종류는 아래의 표와 같다.
| OSI 7 Layers | 프로토콜 이름 (scheme) |
설명 |
| 7. 응용 계층 | HTTP | 웹에서 HTML, JSON 등의 정보를 주고받는 프로토콜 |
| HTTPS | HTTP에서 보안이 강화된 프로토콜 | |
| FTP | 파일 전송 프로토콜 | |
| SMTP | 메일을 전송하기 위한 프로토콜 | |
| SSH | CLI 환경의 원격 컴퓨터에 접속하기 위한 프로토콜 | |
| RDP | Windows 계열의 원격 컴퓨터에 접속하기 위한 프로토콜 | |
| WebSocket | 실시간 통신, Push 등을 지원하는 프로토콜 | |
| 4. 전송 계층 | TCP | HTTP, FTP 통신의 등의 근간이 되는 인터넷 프로토콜 |
| UDP | 양방향의 TCP와는 다르게, 단방향으로 작동하는 훨씬 단순하고 빠른 프로토콜 하지만, 신뢰성이 낮은 인터넷 프로토콜 |
[2] HTTP + 도메인명 = URL? URI? / 웹 애플리케이션 통신 및 URL과 URI의 구분
참고자료
URL구조, Hanseul lee, [첫 페이지에 URL과 URI의 개념을 설명한 사진이 잘 나와있음]
이미지 : URL구조, Hanseul lee
| 명칭 | 설명 |
| scheme | 통신 프로토콜 |
| hosts | 도메인 또는 IP의 이름 |
| 1 port | 웹 서버에 접속하기 위한 통로 |
| url-path | 파일이 위치한 곳까지의 경로 |
| query | 웹 서버에 전달하는 추가 질문 (Get 통신 등) |
1 port의 개념
포트(Port) 번호는 TCP와 UDP가 상위 계층에 제공하는 주소 표현 방식이다.
- 많은 프로그램이 동작중일 컴퓨터 입장에서 응용계층으로 데이터를 전달하려고 할 때,
내부에서 사용중인 많은 프로그램들 중 누구에게 전달해야할지 모른다.- 이를 구분하기 위해, 운영체제는 응용프로그램의 논리적인 주소인 Port를 사용하게 된다.
- 즉 각각의 응용프로그램 (서비스)에 유일한 논리적 주소인 Port번호를 할당하여, 전송계층에서 응용프로그램을 구분할 수 있도록 한다.
[3] DNS
자연어로 주소를 진입하게 되면 컴퓨터는 DNSDomain name system에 진입하여
진입하려는 주소를 시스템 ip주소로 바꾸어 접속을 도와준다.
3. Chrome Network Tab
다양한 크롬 에러 메시지 목록 확인해보는 URL
Chrome Network Tab 사용법
- Inspect Network Activity - Chrome DevTools 101, Google Chrome Developers
4. HTTP Messages
HTTP는 HyperText Transfer Protocol의 줄임말이며, HTML과 같은 문서를 전송하기위한
Application Layer 프로토콜이다.
HTTP는 웹 브라우저와 웹 서버의 소통을 위해 디자인되었다.
- 클라이언트가 1 HTTP Messages 양식에 맞춰 전송하면, 서버도 HTTP Messages 양식에 맞춰 응답
- HTTP는 특정 상태를 유지하지 않는 특징이 있으며, 이를 Stateless protocol이라고도 한다.
[1] 1 HTTP Messages 양식과 구조
참고자료(포스팅과 아래링크 완전 동일)
- HTTP 메시지, mdn web docs
HTTP Messages는 클라이언트와 서버 사이에 데이터가 교환되는 방식이다.
두 가지 유형이 존재하며 아래와 같다.
- 요청 (Requests)
- 응답 (Responses)
개발자는 HTTP Messages를 직접 작성할 필요가 없다.
구성 파일, API, 기타 인터페이스에서 HTTP Messages를 자동으로 완성한다.
구조살펴보기
start line: 이 줄은 항상 한 줄이며, 실행 요청 또는 수행 응답(성공,실패)가 기록된다.HTTP headers: 요청에 대한 설명, 혹은 메시지 본문에 대한 설명이 들어간다.empty line: 요청에 대한 모든 메타 정보가 전송되었음을 알리는 빈 줄이 삽입된다.body: 요청과 관련된 컨텐츠(HTML 폼 컨텐츠 등) 옵션으로 들어가거나, 응답과 관련한 문서가 들어간다. 본문의 존재 유무 및 크기는 첫 줄과 HTTP 헤더에 명시된다.
start line과HTTP headers를 묶어head라고 하며,payload는body라고 이야기한다.
[2] 요청과 관련한 HTTP Messages
참고자료
HTTP 메시지, mdn web docs
- start line (HTTP 메소드/ 요청타켓 / HTTP 버전)
start line은 HTTP메소드, 요청타겟, HTTP 버전으로 구성된다.
번호 순서대로 HTTP 메소드, 요청타겟, HTTP 버전이다.
- 수행할 작업(Get, PUT, POST 등)이나 방식(HEAD or OPTIONS)을 설명하는 HTTP method를 나타낸다.
예를 들어, Get method는 리소스를 받아야하고, Post method는 데이터를 서버로 전송한다.
- 요청 대상(일반적으로 URL이나 URI)또는
프로토콜, 포트, 도메인의 절대 경로는 요청타켓에 작성된다.
- origin 형식: 끝에
'?'와 쿼리 문자열이 붙는 절대 경로입니다. 이는 가장 일반적인 형식이며,GET,POST,HEAD,OPTIONS메서드와 함께 사용한다.POST / HTTP 1.1GET /background.png HTTP/1.0HEAD /test.html?query=alibaba HTTP/1.1OPTIONS /anypage.html HTTP/1.0- absolute 형식: 완전한 URL 형식입니다. 프록시에 연결하는 경우 대부분
GET과 함께 사용됩니다.GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1- authority 형식: 도메인 이름 및 옵션 포트(
':'가 앞에 붙습니다)로 이루어진 URL의 authority component 입니다. HTTP 터널을 구축하는 경우에만CONNECT와 함께 사용할 수 있습니다.CONNECT developer.mozilla.org:80 HTTP/1.1- asterisk 형식:
OPTIONS와 함께 별표('*') 하나로 간단하게 서버 전체를 나타냅니다.OPTIONS * HTTP/1.1
- 마지막으로 HTTP 버전이 들어갑니다. 메시지의 남은 구조를 결정하기 때문에, 응답 메시지에서 써야 할 HTTP 버전을 알려주는 역할을 합니다.
- HTTP Headers
요청의 Headers는 기본구조를 따른다.
- 헤더이름(대소문자 구분이 없는 문자열), 콜론(:) 값을 입력한다.
값은 헤더에 따라 다르며, 여러 종류의 헤더가 있고 아래와 같은 그룹으로 나눌 수 있다.
General headers: 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더이다.Request headers: fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더를 의미한다. User-Agent, Accept-Type, Accept-Language과 같은 헤더는 요청을 보다 구체화한다. Referer처럼 컨텍스트를 제공하거나 If-None과 같이 조건에 따라 제약을 추가할 수 있다.Representation headers: 이전에는 Entity headers로 불렀으며, body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)를 포함하는 헤더이다.
- Body
요청의 본문은 HTTP messages 구조의 마지막에 위치한다.
모든 요청에 body가 필요하지는 않다. GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않다. POST나 PUT과 같은 일부 요청은 데이터를 업데이트하기 위해 사용한다.
body는 다음과 같이 두 종류로 나눌 수 있다.
Single-resource bodies(단일-리소스 본문) : 헤더 두 개(Content-Type과 Content-Length)로 정의된 단일 파일로 구성.Multiple-resource bodies(다중-리소스 본문) : 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지닙니다. 보통 HTML form과 관련있다.
[3] 응답과 관련한 HTTP Messages
참고자료
HTTP 메시지, mdn web docs
- start line (= status line) (프로토콜 버전 / 상태코드 / 상태 텍스트)
start line의 구조는 프로토콜 버전 / 상태코드 / 상태 텍스트로 구성된다.
자세한 설명은 아래와 같다.
- 프로토콜 버전 : 보통
HTTP/1.1이다- 상태코드 : 요청의 성공 여부를 나타낸다.
- 상태 텍스트 : 짧고 간결하게 상태 코드에 대한 설명을 글로 나타내, 사람들이 HTTP 메시지를 이해할 때 도움 되도록한다.
- HTTP Headers
응답에 들어가는 HTTP 헤더는 다른 헤더와 동일한 구조를 따른다.
대소문자를 구분하지 않는 문자열 다음에 콜론(':')이 오며, 그 뒤에 오는 값은 구조가 헤더에 따라 달라진다.
헤더는 값을 포함해 전체를 한 줄로 표시한다.
다양한 종류의 응답 헤더가 있는데, 이들은 다음과 같이 몇몇 그룹으로 나눌 수 있습니다.
General 헤더:Via와 같은 헤더는 메시지 전체에 적용됩니다.- Response 헤더:
Vary와Accept-Ranges와 같은 헤더는 상태 줄에 미처 들어가지 못했던 서버에 대한 추가 정보를 제공합니다.- Entity 헤더:
Content-Length와 같은 헤더는 요청 본문에 적용됩니다. 당연히 요청 내에 본문이 없는 경우 entity 헤더는 전송되지 않습니다.
- Body
본문은 응답의 마지막 부분에 들어갑니다.
모든 응답에 본문이 들어가지는 않습니다.201,204과 같은 상태 코드를 가진 응답에는 보통 본문이 없습니다.넓게 보면 본문은 세가지 종류로 나뉩니다.
- 이미 길이가 알려진 단일 파일로 구성된 단일-리소스 본문: 헤더 두개(
Content-Type와Content-Length)로 정의 합니다.- 길이를 모르는 단일 파일로 구성된 단일-리소스 본문:
Transfer-Encoding가chunked로 설정되어 있으며, 파일은 청크로 나뉘어 인코딩 되어 있습니다.- 서로 다른 정보를 담고 있는 멀티파트로 이루어진 다중 리소스 본문: 이 경우는 상대적으로 위의 두 경우에 비해 보기 힘듭니다.
'Spring > 네트워크, 웹관련지식' 카테고리의 다른 글
| 웹 관련 지식 :) SSR(Server Side Rendering) vs CSR(Client Side Rendering) (1) | 2022.06.08 |
|---|---|
| 네트워크 :) 웹의 동작방식(HTTP, TCP/IP, DNS) 큰 그림, 패킷의 얕은 이해 (0) | 2022.04.26 |
| 네트워크 :) TCP / IP란? OSI 7계층과 TCP / IP 4계층 (0) | 2022.03.15 |