- 시작하게 된 계기 및 다짐 😮
-
이번 코드스테이츠의
백엔드 엔지니어링 개발자 부트캠프에 참여하게 되면서 현직개발자 분들의 빠른 성장을 위한 조언 중 자신만의 블로그를 이용하여 배운 것 들을 정리하는게 많은 도움이 된다 하여 시작하게 되었다.- 그 날 배웠던 것을 길지 않아도 좋으니 정리하며 복습하는 습관 기르기
- 주말에 다음주에 배울 내용들을 예습
- 코딩 문제와 java코드들은 꾸준히 학습
- 자료구조를 이용한 알고리즘 문제 해결 학습
- 학습 목표 😮
| 목표 | 결과 |
|---|---|
| 클라이언트-서버 (HTTP를 이용한 Client/Server 통신 및 API개념 이해) | O |
| 브라우저의 작동 원리_(URL/URO차이, IP주소 및 PORT, DNS<->IP주소 관계) | O |
| HTTP Messages 구조/동작 이해 | O |
- 정리
Client-Server 아키텍쳐
1. 2-티어 아키텍처
- 실제 리소스(상품정보)가 존재하는 곳과 리소스를 사용하는 곳을 분리시켜 놓은 것
- 클라이언트 : 리소스를 사용 하는 곳
- 서버 : 리소스를 클라이언트에 제공 하는 곳(전달해 주는 곳)
ex) 인터넷 쇼핑 홈페이지 <-> 해당 쇼핑몰 어플리케이션
리소스 정보 제공
2. 3-티어 아키텍쳐
- 2_티어 아키텍처의 서버에서 전달하고자 하는 리소스를 따로 저장해 놓은 공간을 마련한 형태(데이터베이스)
- 데이터베이스 : 서버에서 클라이언트로 전달해 줄 리소스를 가져오는 장소
query
responds
ex) 인터넷 쇼핑 홈페이지 <-> 해당 쇼핑몰 어플리케이션 <-> 상품정보 데이터베이스
가져온 리소스 정보 제공 리소스 정보 가져오기
3. HTTP를 이용한 client-server 통신 및 API
- 프로토콜 : client-server 대화수단, 데이터 송/수신 형태, 통신 규약, 약속
ex) HTTP,HTTPS,FTP,SMTP 등 ★사진★참조
- API : (Application Programming Interface)
- 클라이언트가 서버에서 받은 요청 가능한 메뉴판/요청 형태
- 서버가 리소스 전달을 위해 구축해 놓은 메뉴판
- 요청/전송 형태
- 사용자 관리 API 도 존재 (사용자 추가,삭제 등)
- 메소드 : 요청/역할에 따른 간단한 메소드
(1) GET : GET 메서드는 특정 리소스의 표시를 요청, 오직 데이터를 받기만함
(2) POST : POST 메서드는 특정 리소스에 엔티티를 제출, 서버의 상태/변화 일으킴
(3) PUT(PATCH) : PUT 메서드는 목적 리소스 모든 현재 표시를 요청 payload로 바꿉니다.
(4) DELETE : DELETE 메서드는 특정 리소스를 삭제합니다.
# 엔티티 : 통신 개체 (정보를 보내거나 가공 및 받을 수 있는 개념화된 모형)
ex) 다중화 개체
★ 쿼리 String : https://en.wikipedia.org/wiki/Query_string
★ 메소드 설명 : MDN "HTTP 요청 메서드" 참조
URL과 URI
- URI > URL , URI 가 상위 개념
1. URL
- 서버가 제공되는 환경에 존재하는 파일의 위치
- scheme : 통신 방식(프로토콜)을 결정
- hosts : 웹 서버의 이름/도메인/IP를 사용한 주소
- url-path : 웹 서버에서 지정한 루트 디렉토리부터 시작한 웹 페이지,이미지 등 리소스 위치 경로 및 파일명을 나타냄
- port : 웹 서버에 접속하기 위한 통로
: 둘 이상의 프로세스 연결에 의하여, 구분하고 혼합을 막기위해
ex) file://localhost/C:\Users/username\Desktop\
http://www.google.com:80/search?q=java
Schema/hosts/url-path(:port)/query
2. URI
- URI에 query,bookmark를 포함
- query : 웹 서버에 보내는 추가적인 질문
IP와 포트
IPv4 : 2^8 * 4 덩이(2^32) ip주소 체계의 네 번째 버전 .
IPv6 : 2^16 * 8의 주소체계(2^128)
1. IP
- Internet Protocol
- 네트워크에 연결된 특정 PC의 주소를 나타내는 체계
- 모든 PC는 IP 주소체계를 4덩이로 나눔
- 각 덩이당 0 ~ 255까지의 수로 나타낼 수 있음
# TCP : 통신 계층의 프로토콜
# localhost : 127.0.0.1
# broadcast address : 0.0.0.0 / 255.255.255.255로, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소
- 서버의 주소를 broadcast로 설정하면 모든 기기에서 서버 접근 가능
2. port
- 그 주소에 진입할 수 있는 정해진 통로
- 포트 번호는 중복해서 사용할 수 없음
- 0~65,535 까지 사용 가능 (0~1024는 주요 통신을 위해 이미 정해져 있음) ex)22:SSH, 80:HTTP, 443:HTTPS
- ftp 같은 경우 20,21번이 기본 값이다.
# 사용중 포트 번호 : https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
도메인과 DNS
1. Domain
- IP주소를 대신하여 사용하는 주소, 상호명
- codestates.com(domain) <-> 3.34.153.168(IP)
- 가장 왼쪽부터 서브(com)/최상위/루트 도메인으로 구성되어 있음
- 도메인 네임 서버 중 권한 있는 네임 서버는 IP 주소 및 도메인 정보를 관리하는 권한을 가진 서버입니다.
- 존 파일(zone file)은 네임과 클래스, TTL, 레코드 타입, 레코드 데이터로 구성되어 있으며, 도메인과 주소가 매핑된 일종의 테이블이라고 볼 수 있습니다.
- 리졸버는 root, top level domain, 권한 있는 도메인 서버 순서대로 쿼리를 진행하며 IP주소를 알아냅니다.
2. DNS
- Domain Name System
- 도메인 이름 <-> IP 주소 로 변경시켜주는 데이터베이스 시스템
- dns -> ip주소 -> 웹 서버로 전송 -> 클라이언트와 서버 통신
# DNS lookup 과정
(1). 브라우저는 리졸버에게 특정 URL에 대한 IP 주소를 요청합니다.
(2). 리졸버는 우선 기존에 찾아본 도메인 정보가 내용이 담긴 캐시 파일을 살펴봅니다.
(3). 해당되는 도메인 정보가 있다면 즉시 IP 주소를 리턴합니다.
(4). 해당되는 도메인 정보를 찾을 수 없는 경우 DNS 리졸버는 IP주소를 얻기 위해
루트, 탑 레벨, 권한있는 도메인 서버에 차례대로 쿼리를 진행하며 IP 주소를 알아냅니다.
(5). 마지막으로 리졸버는 전달받은 결과값인 IP 주소를 기록하고 브라우저에게 전달합니다.
3. 브라우저 에러 메시지
- 사진 참조
# 여러 에러 메시지 참조 : chrome://network-errors/
# 메시지 해결 참조 : https://support.google.com/chrome/answer/95669#zippy=%2Cpage-loading-error-codes-and-issues
4. Network Tap
- Name_tap : 네트워크 로그, 네트워크 활동 로그
- status : 서버가 반환한 http 응답 코드
- type : 리소스 유형
- initiator : 리소스 요청한 자원
- size : 리소스 크기
- time : 무언가를 받을 때 걸린 시간
참조 : https://youtu.be/e1gAyQuIFQo
HTTP
HTTP Messages
- 클라이언트/서버의 데이터 교환 방식
- HTTP messages 양식에 맞춰서 송신/응답 (사진)
1). start line : 요청/응답(status)의 상태, 첫번째 줄
2). http headers : 요청 지정, 메시지 포함 본문 설명하는 헤더 집합
3). empty line : 헤더와 본문 구분 빈칸
4). body : 요청과 관련된 데이터, 응답과 관련된 데이터,문서 포함
특징
- Stateless(무상태성)
-----------------------------------------------------------------------------
1. 요청 Requests
1). start line
- 수행할 작업(GET, PUT, POST 등)이나 방식(HEAD or OPTIONS)을 설명하는 HTTP method
ex) GET method는 리소스를 받아야 하고, POST method는 데이터를 서버로 전송
- 요청 대상(일반적으로 URL이나 URI) 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에 작성됨, HTTP method마다 요청 형식은 다름
(1) origin 형식 : ?와 쿼리 문자열이 붙는 절대 경로입니다.
POST, GET, HEAD, OPTIONS 등의 method와 함께 사용합니다.
(POST / HTTP 1.1GET /background.png HTTP/1.0HEAD /test.html?query=alibaba HTTP/1.1OPTIONS /anypage.html HTTP/1.0
(2) absolute 형식 : 완전한 URL 형식으로, '프록시에 연결'하는 경우 대부분 GET method와 함께 사용합니다.
(GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1)
(3) authority 형식 : 도메인 이름과 포트 번호로 이루어진 URL의 authority component 입니다.
'HTTP 터널을 구축하는 경우', CONNECT와 함께 사용할 수 있습니다.
(CONNECT developer.mozilla.org:80 HTTP/1.1)
(4) asterisk 형식 : OPTIONS 와 함께 별표() 하나로 서버 전체를 표현합니다.
(OPTIONS * HTTP/1.1)
- HTTP 버전에 따라 HTTP message의 구조가 달라집니다. 따라서 start line에 HTTP 버전을 함께 입력합니다.
ex) GET / home.html HTTP/1.1
(verb/ URI/ version)
2). Header
- 사진
- 헤더이름(대소문자 구분 x 문자열), 콜론(:), 값 입력
(name : value, name : value)
(1) General headers : 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더입니다.
(2) Request headers : fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더를 의미합니다. User-Agent, Accept-Type, Accept-Language과 같은 헤더는 요청을 보다 구체화합니다.
Referer처럼 컨텍스트를 제공하거나 If-None과 같이 조건에 따라 제약을 추가할 수 있습니다.
(3) Representation headers : 이전에는 Entity headers로 불렀으며, body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)를 포함하는 헤더입니다.
3). Body
- http messages 구조의 마지막에 위치, 모든 요청에 body가 필요하지는 않음
- GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않습니다.
- POST나 PUT과 같은 일부 요청은 데이터를 업데이트하기 위해 데이터를 전송함.
(1) Single-resource bodies(단일-리소스 본문) : 헤더 두 개(Content-Type과 Content-Length)로 정의된 단일 파일로 구성됩니다.
(2) Multiple-resource bodies(다중-리소스 본문) : 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지닙니다. 보통 HTML form과 관련이 있습니다.
------------------------------------------------------------------------------
2. 응답(Responses)
- 서버는 반드시 응답을 돌려주어야 함
1). Status line
ex) HTTP/1.1 404 Not Found.
(1) 현재 프로토콜의 버전(HTTP/1.1)
(2) 상태 코드 - 요청의 결과를 나타냅니다. (200, 302, 404 등)
(3) 상태 텍스트 - 상태 코드에 대한 설명
2). Headers
- HTTP headers는 요청 헤더와 동일한 구조
(1) Response headers : 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더로, Vary, Accept-Ranges와 같이 상태 줄에 넣기에는 공간이 부족했던 추가 정보를 제공합니다.
나머지는 같음
3) body
- 모든 응답에 body가 필요하지는 않습니다.
- 201, 204와 같은 상태 코드를 가지는 응답에는 본문이 필요하지 않습니다.
(1) Single-resource bodies(단일-리소스 본문)
- 길이가 알려진 단일-리소스 본문은 두 개의 헤더(Content-Type, Content-Length)로 정의합니다.
- 길이를 모르는 단일 파일로 구성된 단일-리소스 본문은 Transfer-Encoding이 chunked 로 설정되어 있으며, 파일은 chunk로 나뉘어 인코딩되어 있습니다.
(2) Multiple-resource bodies(다중-리소스 본문)
- 서로 다른 정보를 담고 있는 body입니다.
# Stateless
- 큰 특징이라고 기억하는 것으로 충분합니다.
- 상태를 가지지 않음, 필요에 따라 쿠키/세션/API등을 이용한 상태 확인
- 추후 자세히 다룸
퀴즈_요약 정리
HTTP 요청 메서드
- HTTP '동사'
POST : 특징 리소스에 엔티티(개체)를 제출할 때, 데이터가 서버로 들어가야함을 의미, 종종 서버 문제를 일으킴
GET : 특정 리소스 표시 요청 , GET 요청은 데이터를 가져올 때만 사용
PUT : 요청 페이로드(payload)를 사용해 새로운 리소스를 생성하거나, 대상 리소스를 나타내는 데이터를 대체합니다.
DELETE : 특정 리소스를 삭제
(CRUD : creat,read,update,delete(post,get,put,delete))
HEAD : GET과 동일하지만 응답 본문을 포함하지 않음
CONNECT : 목적 리소스로 식별되는 서버로의 터널을 맺음
OPTIONS : 목적 리소스의 통신을 설정하는 데 사용
TRACE : 목적 리소스의 경로를 따라 메시지를 loop-back 테스트
PATCH : 리소스의 부분만을 수정하는 데 사용
# 멱등성 : 여러번 보내도 한번 보낸것과 같은 효과, 서버 리소스도 동일하게 남을 때
통계,기록등을 제외하면 어떠한 부수효과도 존재해서는 안됨
(GET,HEAD,PUT,DELETE)
---
HTTP 메시지
- 클라이언트/서버 데이터 교환 방식/형식
- 요청/응답 존재
- 개발자 대신 sw/browser, froxy, server가 메시지 대신 작성
- 설정파일,API,다른 인터페이스를 통해 제공
(1) start-line : 실행되어야 할 요청/수행에 따른 성공/실패 기록
(2) http-header : 요청에 대한 설명, 메시지 본문에 대한 설명
(3) empty : 요청에 대한 메타 정보가 전송됬음을 알리는 빈줄
(4) body : 요청과 관련된 내용이나 응답과 관련된 문서, 본문의 존재 유무 및 크기는 첫줄과 HTTP 헤더에 명시
이전에 정리한거 참조
---
HTTP의 무상태성(stateless) : HTTP는 특정 상태를 담고 있지 않으며, 이전 요청이나 다음 요청을 기억하지 않음
---
HTTP 상태 코드
- 200 : OK, 성공적 응답
- 302 : found, 리 다이렉션할 URL확인
- 404 : not found, 잘못된 서버 요청에 페이지 찾기 불가
- 406 : not acceptable : 클라이언트가 응답 코드를 받지 못함
- 500 : Internal Server Error : 서버에서 에러 발생
- 2xx : 성공
- 3xx : 리다이레션 필요
- 4xx : 클라이언트 요청
- 5xx : 서버 내부 오류
- https://developer.mozilla.org/ko/docs/Web/HTTP/Status 참조
---
MIME Type - Content type
- https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/MIME_types
---
브라우저 동작 원리 #참조
- https://d2.naver.com/helloworld/59361
- 피드백 😮
-
클라이언트-서버의 관계와 HTTP를 이용한 통신 방법 및 구조를 살펴보았는데, 처음 보는 개념이 여서 정리할 것도 많고 외워야 할 것도 많은것 같다. 기본적은 HTTP 메서드들인 GET,POST등의 개념과 HTTP 메러메시지등의 것들도 실제 작업을 할 때 많은 필요가 있어 보인다.
-
URI/URL의 개념과 DNS를 이용한 IP주소와 Domain의 변경 IP/PORT의 개념을 학습하였다.
-
HTTP메시지를 통해 실제 클라이언트가 서버에 요청을 보내고 서버로부터 요청을 받는 형태를 공부하였는데, 나중에 프로젝트/현업에서 실제 사용하므로 잘 익혀두어야 겠다.
- 앞으로 해야 될 것 😮
- 매일 꾸준히 할 것
- 꾸준히 velog 작성
- Java 언어 및 Algorithm 공부(Coding-Test)
- 틈틈히 운동 하기
- 내일 해야 할 것
- 추가적인 Network개념 학습 및 복습
Will be great Backend-developer