IT's 잡탕찌개 블로그

HTTP Header 란?

http header란 http 통신에서 client와 server가 요청 또는 응답에 부가적인 정보를 전송할 수 있도록 해준다.

Header 는 대소문자를 구분하지 않는 key값, 그에 대응되는 value값으로 이루어져 있다.

header는 4가지 분류로 구분할 수 있는데 아래와 같이 그룹화 할 수 있다.

. generic header

 - 요청, 응답에 모두 적용되지만 message body 와는 관계없는 header

. request header

 - 패치될 resource나 client 자체에 대한 정보를 포함하는 헤더

. response header

 - 위치 또는 server 자체에 대한 정보와 응답에 대한 부가적인 정보를 포함하는 헤더

. entity header

 - 컨텐츠 길이나 MIME 타입과 같이 Entity body에 대한 자세한 정보를 포함하는 헤더

대표적인 Header의 종류[Request]

. Host : 요청하려는 서버 호스트의 이름과 포트번호

. User-agent : client의 프로그램 정보

. Referer : 바로 직전에 머물렀던 web irl 주소 [ 경우에 따라서 null 일 수도 있다.]

. Accept : client가 처리 가능한 미디어 타입 종류 정보

. Accept-charset : client가 지원 가능한 언어 계열

. Accept-encoding : client가 지원 가능한 언어 encoding

. Content-location : 해당 개체의 실제 위치

. Origin : 서버로 Post 요청을 보낼 때 요청이 어느 주소에서 시작되는지 나타내는 값

. Cookie : 쿠키 값

대표적인 Header의 종류[Response]

. Location : redirect시 이동해야할 url 이 담겨있다.

. Server : web server의 종류

. Age : max-age 시간 내에서 얼마나 흘렀는지 초단위로 알려주는 값.

참고

 - https://hazel-developer.tistory.com/145

 - https://developer.mozilla.org/ko/docs/Web/HTTP/Headers

이번 포스팅에서는 MSA를 설계할 때 고려해야할 것들, 주의할 점등에 대해서 알아보자.

MSA의 설계 철학
. service의 크기는 작아야한다.
. test 및 자동 배포를 하여 유지보수 부담을 낮춰야 한다.
. 각 작업자는 자신의 코드영역만 작업할 수 있어야 한다.
. 각 service는 유연하고 회복력이 있게 구성되어야 하며, 해당 service만으로도 완전해야 한다.
. 각 service는 구분되며 이에 필요한 기술스택은 다양할 수 있다.

위의 설계 철학에 따른 구조를 위 그림과 같다고 할 수 있을 것이다.
일부 시스템은 단일 서비스로 구현되고 어떠한 시스템은 여러 service에 분산 될 수 있다.
분산되는 service의 경우 HTTP를 통해 통신하거나 Kafka와 같은 메세지 브로커를 비동기식으로 사용해 구현될 수 있다.
그렇다면  MSA 적용시 어떠한 점들을 고려해야 할까?
우선 우리의 프로젝트가 과연 MSA를 적용하는것이 옳은지 생각해봐야한다.
만약 MSA를 적용하기에 비효율적으로 복잡하거나 런타임 시 결합이 긴밀할 것으로 생각된다면 MA를 적용하는 것이 좋을 수 있다.
MSA를 적용하기로 했다면 이제 분산 작업을 설계할 차례이다.
MSA를 사용할 때 우리는 service를 분산시킬 것이며, 이는 각 service가 고유 DB를 지닌다는 얘기가 된다.
이로인해 DB에 대해 어떻게 접근할 지를 고려해야 하며 DB와 관련된 여러가지 문제가 발생할 수 있다. 해결책으로는 아래 이미지의 여러 패턴을 적용하는 것이 있지만 이 내용은 다소 분량이 커서 다른 포스팅에서 다루기로 한다.

DB외에도 고려해야 할 점은 또 있다.
우선 service를 구분하는 범위에 대한 기준을 정해야 한다.
단순히 A service로 묶을지 혹은 A의 기능인 A`와 A``를 개별 service로 묶을지에 대한 기준이다.
이러한 기준은 비즈니스 혹은 해당 서비스에 따라서 달라질 수 있다.
그 외에도 service내에서 API를 어떻게 설계할지, 또는 service간의 종속성과 배포 용이성, 장애 대응을 어떻게 할지 등등 고려해야할 점이 많다.


참고 -
https://microservices.io/patterns/microservices.html https://ko.m.wikipedia.org/wiki/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4

MA란 무엇인가?
Monoilithic Architecture의 경우 전통적인 개발 방식으로 하나의 프로젝트 속에 여러 기능을 모두 포함한다.

MA의 특징
MA의 경우 기능이 모듈별로 쪼개지는 것이 아니기 떄문에 하나의 프로젝트에 전체 APP이 다 포함된다.
이러한 구조로 인해서 기능, 모듈이 추가될 때마다 프로젝트가 커지게 된다.

MA의 장점
아무래도 구조등을 고민할 필요가 적어 초기에 개발하기가 편하다.
더불어 모든 기능이 같은 내부에 존재하기 때문에 별도의 통신이 없이 다른 기능을 직접 사용할 수 있다.  

MA의 단점
시간이 지나 프로젝트 규모가 커질수록 유지보수 규모와 비용이 커지며 확장이 점점 힘들어진다.
그외의 사소한 기능 수정임에도 전체 App을 재기동해야하는등의 단점이 존재한다.

MSA 란 무엇인가?
msa(micro service architecture)란 MA에 반대되는 개념으로
여러개의 작은 service로 구성되어 각 service가 독립적으로 개발 되고 배포되는 구조를 의미한다.

MSA 의 특징
MSA는 MA와 달리 각 기능별로 독립적으로 배포 및 개발이 되기 때문에 전체적으로 시스템이 분산되어 있다.
이로 인해서 각 기능별로 개발, 배포가 독립적으로 가능하며 MA에 비해서 규모 및 기능을 확장하기가 쉽다.
또한 유지보수가 용이하다.

MSA의 장점
각 service간의 독립성으로 인해서 확장성과 유연성이 높아진다.
가령 cloud 환경에서 특정 기능에 부하가 몰리는 경우 해당 기능과 관련된 instance 규모만 확장하면 된다.
또한 각 service가 구분되어 있기 때문에 일부 service의 장애가 다른 service에 영향을 끼치지 않는다.

MSA의 단점
반면 MSA 역시 단점이 존재하는데 각 service가 독립되어 있기 때문에 service간의 통신을 고려해야한다.
이로 인해서 각 service와의 연결구조 및 관리가 다소 복잡해진다.
추가로 초기 구조 세팅에 소모되는 비용이 다소 크다.

MSA가 적용된 예
MA의 경우 프로젝트 크기가 별로 크지 않을때 많이 적용되며 반대로 MSA의 경우 대규모 프로젝트에 적합하다.
간단하게 게임분야의 경우 login server와 lobby server, battle server, guild server 등으로 구분하여 service를 구현하는 경우도 MSA로 볼 수 있을 것이다.

이번 포스팅에서는 Elasticsearch에 대해서 알아보자.

Elasticsearch란?
Elasticsearch는 Lucene을 기반으로 개발된 검색엔진으로 다양한 방식의 검색을 할 수 있다.
또한 cluster를 구성할 수 있으며, cluster는 여러개의 node로 구성된다.

elasticsearch에서 중요한 개념은 아래와 같다.
. 색인(index)과 역색인(reverse index)
. data의 집계
.cluster
대충 요약하자면 cluster 환경에서 색인과 역색인을 통해 빠른 검색이 가능하며 data에 대해서 집계정보 까지 활용이 가능하다는 것이라고 이해하면 될 것 같다.

Elastic에서는 각 data를 json 형태로 저장한다.
해당 data들은 Index라는 개념으로 구분되어 저장되는데 여기서 Index는 색인의 개념이라기보다는 RDB의 Table과 유사한 개념이라고 생각하면 된다.
해당 Index들은 저장되는 data에 대한 항목별로 각 type 정보들을 정의할 수 있다.
ELK stack에서 data를 import 할 때 자동으로 설정해서 Index가 생성되긴하지만 해당 type에 대해서는 확인을 하는 것이 좋다.
이유로는 특정 항목의 값이 원래는 실수 범위이지만 import 하는 data가 모두 정수값인 경우 index가 type을 정수로 지정하는 경우가 생길 수 있기 때문이다.
cluster의 경우 elastic이 기본적으로 방대한 양의 data를 저장하고 이를 검색에 활용하기 때문에
가령 하드웨어의 용량을 초과하거나 혹은 너무 많은 용량을 지녀 검색이 느려지는 등의 문제가 발생할 수 있다.
이를 방지하기 위해서는 cluster 환경을 구축하는 것이 좋은데 cluster에서 sharding 과 replica를 구현할 수 있기 때문이다.
shard는 Index를 일종의 조각으로 분해하는 것이다.
Index 생성 시 원하는 갯수로 shard 를 지정할 수 있고 이 shard 자체 역시 온전한 Index의 역할을 한다.
해당 shard들은 data volume을 수평분할 및 확장이 가능해지게 하며 여러 shard에 분산된 만큼 검색 성능을 더 끌어 올릴 수 있다.
이 때 오류가 일어나 해당 shard에 대해서 접근을 못하거나 사라지게 되는 경우를 대비하여 replica shard라는 것 역시 존재한다(이하 replica).
replica를 만들면 원본 shard 혹은 해당 shard를 지닌 node에 문제가 발생하더라도 검색기능에는 문제가 생기지 않는다.
물론 해당 replica는 원본 shard와 다른 node에 존재한다.

실제로 elasticsearch 의 설치에 대해서는 다음 포스트에서 알아보자.

참고 - https://nanbuja.com/entry/Elasticsearch%EB%9E%80-%EA%B0%9C%EB%85%90-%EB%B0%8F-%EC%A2%85%EB%A5%98-RDBMS%EC%99%80-%EC%B0%A8%EC%9D%B4

ELK stack이란?
ELK stack이란 말은 서버 개발자라면 한번 들어봤을 것이다.
ELK stack이란 Elasticsearch Logstash Kibana를 구축하여 활용하는 환경을 의미한다고 보면 된다.
ELK를 구성하는 것들 (위의 3가지)는 각자 맡은 역할이 다르고 장단점도 존재하지만 이 포스팅에서는 크게 다루지는 않고 간단하게 역할만 짚고 넘어간다.

Elasticsearch
elasticsearch는 검색엔진이다.
JAVA 언어 기반으로 구현되었으며 data의 검색 및 집계에 사용된다.

Logstash
다양한 data source로부터 data를 수집 및 집계, 가공할 수 있다.
ELK stack에서의 역할은 수집 및 가공된 data들을 Elastic에 전달하는 역할을 맡는다.

Kibana
kibana는 ELK stack에서 모니터링 및 시각화를 담당한다.

ELK stack의 구성형태 및 처리 순서
. Data processing ( Logstash )
-> log, 혹은 DB등에서 data 수집 ( input )
-> data 변환 ( filter )
-> data 전달 ( output )
. Storage ( Elasticsearch )
-> data의 저장
-> data의 분석
-> data의 관리
. Visualize ( Kibana )
-> dashboard등 다양한 시각화 자료 확인 가능
-> elastic 환경에 대한 접근 제어

ELK의 장점
ELK 의 경우 전반적인 장점으로는 빠른 검색과 특정 data들에 대한 분석, 시각화를 손꼽는다.
더불어 개발자가 아니더라도 ata에 대한 집계 및 검색을 하기 쉽다는것도 장점이다.
그 외의 다양한 모듈등이 존재하며 유연하게 data를 분석,가공 할 수 있는 생태계라는것 역시 장점이다.
실제 작성자가 참여한 프로젝트에서도 ELK를 활용했었는데 서버LOG를 빠른속도로 보기 쉽도록 가공된 상태로 조회한다는게 좋았던 기억이 있다.

ELK의 단점
E, L, K의 각각의 단점이 아닌 ELK stack 자체의 단점으로는 아무래도 리소스를 많이 사용한다는 점과 용량 역시 많이 차지한다는 점이 있다.
또한 ELK stack 환경을 구축하는 것이 해당 정보분석에 다소 과하진 않은가 에 대해서도 충분히 고려해야 한다.

DB 혹은 server를 개발하다보면 UUID란 말을 한번쯤은 들어봤을 것이다.
이번 포스팅에서는 UUID란 무엇이고 그 외 추가적인 내용을 알아보자.

UUID란?
UUID란 범용 고유 식별자(Universally Unique Identifier)의 약자이다.
간단하게는 다른 리소스중에서 해당 리소스를 고유하게 식별해주는 값 이라고 생각하면 된다.

이렇게만 보면 기본적으로 ID를 auto increment해주는 것과 차이가 없다고 생각할 수도 있다.
일반적인 ID와는 어떠한 점에서 차이가 있을까?

우선 UUID는 주로 분산 컴퓨팅 환경에서 사용되는 식별자로, 중앙 관리 시스템에서 순차적으로 일련번호를 부여하는 것이 아니더라도 고유한 값을 보장할 수 있어야 하기때문에 탄생하게 되었다.
- 물론 UUID 역시 완벽하게 고유성을 보장하지는 못한다.

UUID의 구조
UUID는 128 bit(16byte)로 구성된다.
UUID는 32자리의 16진수로 표시되는데 여기서 각 8-4-4-4-12 자리마다 의미하는 내용이 다르다.

UUID의 종류
UUID는 버전이 여러개 존재하는데( 1 ~ 5 ) 대표적으로 1, 4 버전이 많이 사용된다.
1 버전의 경우 UUID 생성을 timestamp를 기준으로 생성하며,
4 버전의 경우 무작위 랜덤 생성을 통해 UUID를 발급한다.


UUID의 하이픈(-)을 제거해도 괜찮은가?
UUID를 발급 받으면 해당 문자열에는 하이픈이 포함되어 있다. 굳이 문자열 길이를 더 늘린상태로 활용해야할 필요가 있을까? 우선 UUID에 하이픈이 포함되는 것이 국제 표준이며 유일성을 보장받을 수 있다.
다만 하이픈을 없앤다고 해도 유일성이 깨지는 확률이 상당히 낮다

우리는 rpgoramming을 하면서 thread라는 말을 자주 듣게 된다.
이번 포스팅에서는 thread란 무엇인지에 대해서 간단하게 알아보자.

thread란 ?
thread는 어떠한 program 내부에서, 특히 process 내에서 실행되는 흐름을 의미한다.
일반적으로 하나의 program은 하나의 process를 생성하지만 하나의 process안에서는 여러개의 thread를 생성, 실행할 수 있다.
이러한 실행 박식을 multithread라고 한다.

process와 thread의 차이
multithread와 multiprocess는 여러 흐름이 동시에 진행된다는 점에선 같다고 볼 수 있다.
(multiprocess : 여러 program이 동시에 실행되는 상태)
다만 multiprocess는 각 process가 독립적으로 실행되며 특정 process가 실행되기 위해선 context switching을 통해 cpu를 점유해야 한다.
반면 multithread의 경우 동일한 process내에서의 작업 흐름이므로 특정 메모리를 공유하며 이로 인해 동일 process내의 다른 thread가 cpu를 점유할 때 context switching이 발생하지 않는다.

multithread의 장점
multithread의 장점은 cpu가 여러개인 환경에서 각각의 thread가 cpu를 하나씩 점유하면 작업 처리 속도가 훨씬 빨라진다는 것이다.

multithread의 단점
다만 multithread의 단점도 여러가지가 존재하는데 우선 특정 thread 간의 실행 순서에 대해서 알수가 없다는 것이다.
간단한 예로 여러 thread가 특정 변수의 값을 1씩 증가시키는 경우 code 상에서는 단 1줄로 변수값을 1증가시키지만, 실제 기계어 레벨에서 살펴본다면 레지스터에 대한 작업 단위로 구분할 수 있고 thread의 cpu점유가 어떻게 되는지에 따라서 변수의 값이 증가하지 않을 수도 있다.
이러한 순서 보장이 안되기 떄문에 여러가지 문제가 발생할 수 있고 이를 해결하기 위한 구현 난이도가 높아진다.

thread의 종류
thread는 해당 thread를 지원하는 주체에 따라서 2가지로 구분된다.

user level thread
사용자 스레드는 kernel 영역 상위의 app영역에서 지원되며 일반적으로는 사용자 라이브러리를 통해서 구현된다.
사용자 라이브러리는 스레드의 생성 및 스케줄링에 대해 관리기능을 제공한다.
동일한 메모리 영역에서 스레드가 생성 및 관리 되므로 속도가 빠른 장점이 있지만, 시스템 호출 등의 요청이 있을 시 다른 스레드들이 유휴상태에 빠지게 되는 단점이 있다.
이는 kernel이 process 내부의 thread를 인식하지 못하기 때문에 process를 대기상태로 전환시키기 때문이다.

kernel level thread
kernel level thread는 OS가 지원하는 thread 기능으로 구현되며, kernel이 thread의 생성, 스케줄링을 담당한다. thread가 system call등으로 중단되더라도, kernel은 process내의 다른 thread를 중단시키지 않고 실행시켜준다.

thread data
thread는 두가지 data가 존재한다. thread자체의 기본 ata는 실행과 관련된 data를 지니며, 자신만의 고유한 thread id, PC(program counter), register, stack을 지닌다.
code, data, file등의 자원은 process의 자원을 사용하며 동일 process하의 다른 thread들과 공유한다.
기본 data외의 특정 thread에만 필요한 정보들이 필요한 경우도 존재하는데,
이러한 data는 (TSD)thread specific data라고 부른다.
예를 들면 각 thread 별로 처리하는 transaction 이 다를 경우 이에 대한 transaction id를 기억해야한다.
그 외의 예로는 TLS(thread local storage) 등등이 있다.

참고-
https://ko.m.wikipedia.org/wiki/%EC%8A%A4%EB%A0%88%EB%93%9C_(%EC%BB%B4%ED%93%A8%ED%8C%85)

우리는 개발을 하면서 process라는 말을 자주 접한다. 이번 포스팅에서는 process란 무엇인가를 포함해서 다양한 내용을 다뤄 볼 것이다.

process란 무엇인가?
process는 컴퓨터에서 연속적으로 실행되고 있는 program을 의미하며
종종 cpu scheduling 대상인 task와 동일한 의미로 사용된다.
process는 program 그 자체 또는 program의 상태가 memory 상에서 실행되는 작업 단위를 지칭한다.
- program A를 여러개 실행하면 여러개의 process가 생성된다.

process의 구조
process의 구조는 크게 아래와 같이 구분된다.
. text : 컴파일 된 code 가 저장된느 영역
. data : 전역변수 및 초기화된 data가 저장되는 영역
. heap : code 상에서 동적으로 생성되는 ata가 저장되는 영역
. stack : 함수 콜스택, 지역변수 등이 저장되는 영역

process의 상태와 그에 대한 설명
process는 아래와 같은 상태를 가진다.
. create
- proces를 생성하는 상태
. running
- process가 cpu를 점유하고 관련 명령어들을 실행 중인 상태
. ready
- process가 CPU를 사용하고 잇지는 않지만 점유를 준비중인 상태.
. waiting
- process가 특정 input 혹은 signal을 기다리는 상태.
. terminated
- process가 종료된 상태


process의 상태 변화
하나의 program이 실행되면 그에 대응하는process가 생성되어 준비 리스트에 들어간다.

그 후 이미 준비 리스트에 있던 다른 process가 CPU를 할당받아 떠나면 순차적으로 앞으로 나아간다.

process가 겪는 상태 변화는 아래와 같다

. dispatch : ready -> running

. block : running -> blocked

. wakeup : blocked -> ready

. timeout : running -> ready

process mode

process는 두가지의 mode가 존재한다. 각각 UserMode와 KernelMode이다.

우선 간단하게 알아둘 것으로는 운영체제는 기본적으로 가상 메모리를 user 영역과 kernel 영역으로 구분한다.

 kernel 영역은 kernel, kernel 확장기능, 대부분의 장치 driver를 실행하기 위한 예비 공간이다.

반면, user 영역은 모든 사용자 모드의 application들이 동작하는 영역으로 해당 메모리는 필요할 때 Paging 처리 될 수 있다.

User 영역의 process는 일반적으로 고유한 가상 메모리 영역에서 실행되며, 다른 process의 메모리에 접근할 수 없다.

참고 -
https://ko.wikipedia.org/wiki/%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4

HTTP란 무엇인가?
위키에서 HTTP에 대한 설명은 아래와 같다.
HTTP는 W3 상에서 정보를 주고받을 수 잇는 protocol이다.
주로 HTML 문서를 주고받을 때 사용되며 주로 TCP를 사용한다.
(HTTP/3 부터는 UDP를 사용할수 있다고 함)

반면 MSDN에서는 아래와 같이 설명하고 있다.
HTTP는 HTML 문서와 같은 "리소스"들을 가져올 수 있도록 해주는 PROTOCOL입니다.
HTTP는 WEB에서 이루어지는 모든 데이터 교환의 기초이며, Client-Server protocol이다.
수신자 측에 의한 요청이 초기화 되는 protocol을 의미한다.
하나의 오나전한 문서는 텍스트, 레이아웃 정보, 이미지, 비디오, 스크립트 등의 하위 문서들로 재구성된다.
client와 server 들은 개별적인 message를 통해 통신하며 이를 각각 request, response라고 한다.
HTTP는 Application layer의 protocol로 TCP 혹은 암호화된 TLS를 통해 전송된다.
HTTP의 호가장성 덕분에 오늘날 하이퍼 텍스트문서, 이미지, 비디오 등의 정보를 server로 전달하기 위해서 사용되기도 한다.


HTTP기반 시스템의 구성 요소
HTTP 는 기본적으로 client-server protocol이다.
요청은 단 하나의 개체에 의해서 전송되며, 개별적인 요청들은 서버로 보내진 후 server에서는 이 요청에 대해서 처리한 결과를 응답에 담아 전달한다.
이 요청과 응답의 사이에는 여러 개체가 존재하는데 gateway, proxy server 등이 있다.

HTTP에서의 client란?
실제 User를 대신해서 동작하는 모든 도구를 의미한다.
브라우저가 될 수도 있고 web을 크롤링하는 bot이 될수도 있다.
브라우저는 항상 server에 요청을 보내는 개체이며 절대 server가 될 수 없다.(가끔 혼동하는 사람이 있다.)

HTTP에서의 Web Server란?
Server는 Client 요청에 대해서 문서(응답)을 제공하는 역할을 한다.
논리적으로는 단일 기계이지만 실제로는 복합 장치(로드밸런싱, DB, 캐시서버 등)들로 구성 될 수 있다.
  
HTTP의 특징
. HTTP는 간단하다.
. HTTP는 확장가능하다.
. HTTP는 stateless이다.

HTTP의 기본적인 순서
. 요청을 보내거나 응답에 사용 될 TCP 연결을 준비한다.
. HTTP message를 전송한다. 이 때 HTTP essage는 HTTP 버전에 따라 암호화 되기도 한다.
- HTTP /2 이전 버전의 경우 message가 평문이라서 인간이 읽을 수 있지만 HTTP/2는 압축 및 암호화 된다.
. Server에 의해 전송 된 HTTP 응답을 읽는다.
. 이후 TCP연결을 닫거나 다른 요청을 위해서 재사용한다.


HTTP 요청에는 무엇이 있는가?
HTTP는 웹 page를 로드하는데 필요한 정보를 요청하는 방식으로 인터넷에서 이루어진 HTTP 통신에는 여러 정보를 포함하고 있다.

HTTP Request 에 포함된 정보
. HTTP 버전 정보
. URL
. HTTP Method
. HTTP HEADER
. HTTP body

HTTP Method란?
HTTP Method는 HTTP 요청을 통해 Server에 기대하는 작업을 나타낼 수 있다.
Method는 GET, POST, PATCH 등 다양한 종류가 있고 각각의 Method 별로 Server에 기대하는 작업이 다르다.
가령, GET Method의 경우 요청에 대한 응답으로 특정 정보를 수신하는 것을 기대하는 반면, POST Method의 경우 요청정보에 포함된 특정 값들이 Server의 data에 반영되는것을 기대한다.

HTTP HEADER란?
HTTP HEADER에는 Dictionary Data가 저장된다.
키와 대응되는 값이 포함되어 있으며 HEADER는 모든 HTTP요청 및 응답에 포함된다.
HEADER 에는 브라우저가 활용하거나 요청 데이터와 관련된 정보등 핵심정보들이 포함된다.


HTTP Request Body
HTTP Request Body에는 여러가지 정보가 포함되어 있거나 어떤한 정보도 없을 수 있다.
실제 현실에서는 주로 특정 유저의 data가 포함되거나 검색을 요청 시 검색타입 및 검색어가 포함되어 있다.

HTTP Response에 포함된 정보
. HTTP Status Code
. HTTP HEADER
. HTTP Request Body

HTTP Status Code란?
HTTP Status Code는 HTTP요청에 대한 상태를 나나태며 해당 요청이 정상적으로 응답되었는지 등에 대한 여부를 구분할 수 있게 각각 여러 값을 지닐 수 있다.
(HTTP Status Code에 대해서는 별도 포스팅할 예정)

HTTP Response Body 란?
HTTP Response Body 는 HTTP Request Body 처럼 응답에 포함되는 여러 정보를 포함한다.
가령, HTTP Request Method가 GET인 경우에 대한 응답일 경우 해당 URL에 대한 HTML 문서가 포함된다.

HTTP HEADER
HTTP Response  의 경우에도 HEADER를 포함한다.
이 때 HEADER에 포함되는 정보는 응답 본문의 내용이 어떠한 컨텐츠 타입인지, 해당 데이터의 언어 형식 등 중요한 정보가 포함되어 전달된다.



참고 -
https://developer.mozilla.org/ko/docs/Web/HTTP/Overview https://www.cloudflare.com/ko-kr/learning/ddos/glossary/hypertext-transfer-protocol-http/

client
. client는 일반적으로 WEB에 연결된 장치를 의미한다.
. 모바일 장치, pc, web browser 등이  client 에 속한다.

server
. 일반적으로 web page, site을 저장하거나 application 을 구동하는 장비를 server라고 지칭한다.


web page 접속 시 발생하는 일들.
. 브라우저는 DNS에 입력받은 URL 주소를 요청 후 실제 IP를 확인.
. 브라우저는 server 로부터 web site의 사본을 HTTP을 사용하여 요청한다.
. server는 요청을 수신 후 응답코드와 함께 응답 메세지를 브라우저에 전달한다.
-> TCP 소켓을 통한 응답이기때문에 Strem 형식으로 전달 및 수신된다.
. 브라우저는 응답을 수신 후(해당 stream을 모두 수신 및 조립 완료 후) web page로 유저에게 노출한다.
-> 일반적인 경우에 html 이 포함된 응답이 전달되므로 이렇게 설명함.



참고 : https://developer.mozilla.org/ko/docs/Learn/Getting_started_with_the_web/How_the_Web_works