인터넷 통신IP (Internet Protocol)TCP, UDPPORTDNS
지정한 IP 주소(IP Address)에 데이터 전달패킷(Packet)이라는 통신 단위로 데이터 전달패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송ex) 상대 서버가 꺼져있는 등 불능 상태일지라도 그냥 보냄. 대상 서버가 패킷을 받을 수 있는 상태인지 모름중
애플리케이션 계층 - HTTP, FTP전송 계층 - TCP, UDP인터넷 계층 - IP네트워크 인터페이스 계층전송 제어 프로토콜 (Transmission Control Protocol)연결지향 - TCP 3 way handshake (가상 연결)데이터 전달 보증 (데이
IP는 목적지 서버를 찾는 것, PORT는 서버 안의 애플리케이션을 구분하는 것패킷을 보낼 때 출발지 IP, PORT와 목적지 IP, PORT를 담아 보내기 때문에서버에서도 클라이언트에게 응답 할 수 있음ex) IP는 아파트, PORT는 몇동/몇호0 ~ 65535 할당
IP는 기억하기 어렵다IP는 변경될 수 있다도메인 네임 시스템 (Domain Name System)전화번호부도메인 명을 IP 주소로 변환
URL (Uniform Resource Locator) - 리소스가 있는 위치를 지정URN (Uniform Resource Name) - 리소스에 이름을 부여위치는 변할 수 있지만, 이름은 변하지 않는다.URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지
https://www.google.com/search?q=hello&hl=ko웹 브라우저(100.100.100.1) -> 구글 서버(200.200.200.2)이렇게 웹 브라우저에서 HTTP 요청 메세지를 만든다.다음은 만든 HTTP 메세지를 전송한다.웹 브라우
HTTP 메세지에 모든 것을 전송HTML, TEXTIMAGE, 음성, 영상, 파일JSON, XML (API)거의 모든 형태의 데이터 전송 가능서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용지금은 HTTP 시대TCP: HTTP/1.1, HTTP/2UDP: HTTP
클라이언트 서버 구조무상태 프로토콜(스테이스리스), 비연결성HTTP 메세지단순함, 확장 가능Request Response 구조클라이언트는 서버에 요청을 보내고, 응답을 대기서버가 요청에 대한 결과를 만들어서 응답
클라이언트 서버 구조무상태 프로토콜(스테이스리스)비연결성HTTP 메세지단순함, 확장 가능스테이스리스(Stateless)서버가 클라이언트의 상태를 보존 X장점: 서버 확장성 높음(스케일 아웃)단점: 클라이언트가 추가 데이터 전송상태 유지: 중간에 다른 점원으로 바뀌면 안
클라이언트 서버 구조무상태 프로토콜(스테이스리스)비연결성HTTP 메세지단순함, 확장 가능클라이언트3이 요청하고 서버가 응답하는 상황에서도,클라이언트1과 클라이언트2는 여전히 서버와 연결이 유지되어 있음.단점: 클라이언트1이 놀고 있어도 서버는 계속 유지되기 때문에 서버
클라이언트 서버 구조무상태 프로토콜, 비연결성HTTP 메세지단순함, 확장 가능HTTP의 방향이 Stateful(상태 유지) -> Stateless(무상태)로 진화(?)했다. 또한 비연결성이다.클라이언트와 서버 간의 연결을 계속 지속한다면 자원 고갈이 일어나기 때문이다.
HTTP 메시지에 모든 것을 전송HTTP 역사 HTTP/1.1을 기준으로 학습하면 됨HTML, TEXTIMAGE, 음성, 영상, 파일JSON, XML거의 모든 형태의 데이터 전송 가능서버 간에 데이터를 주고 받을 때도 대부분 HTTP 사용지금은 HTTP 시대!start
회원 정보 관리 API 만들어보기회원 목록 조회회원 조회회원 등록회원 수정회원 삭제회원 목록 조회 /read-member-list회원 조회 /read-member-by-id회원 등록 /create-member회원 수정 /update-member회원 삭제 /delete-
GET: 리소스 조회POST: 요청 데이터 처리, 주로 등록에 사용PUT: 리소스를 대체, 해당 리소스가 없으면 생성 (기존 파일이 있으면 덮어쓰기, 없으면 생성)PATCH: 리소스 부분 변경DELETE: 리소스 삭제기타 메서드HEAD: GET과 동일하지만 메세지 부분
리소스를 대체리소스가 있으면 대체리소스가 없으면 생성쉽게 이야기해서 덮어버림클라이언트가 리소스를 식별클라이언트가 리소스 위치를 알고 URI 지정POST와 차이점리소스 부분 변경PATCH가 지원이 안되는 서버에서는 POST를 쓰면 된다.리소스 제거
안전(Safe Methods)멱등(Idempotent Methods)캐시가능(Cacheable Methods)호출해도 리소스를 변경하지 않는다.Q: 그래도 계속 호출해서, 로그 같은게 쌓여서 장애가 발생하면?A: 안전은 해당 리소스만 고려한다. 그런 부분까지 고려하지
클라이언트에서 서버로 데이터 전송HTTP API 설계 예시쿼리 파라미터를 통한 데이터 전송GET주로 정렬 필터(검색어)메세지 바디를 통한 데이터 전송POST, PUT, PATCH회원 가입, 상품 주문, 리소스 등록, 리소스 변경정적 데이터 조회이미지, 정적 텍스트 문서
POST 기반 등록예) 회원 관리 API 제공PUT 기반 등록예) 정적 컨텐츠 관리, 원격 파일 관리웹 페이지 회원 관리GET, POST만 지원회원 목록 /members -> GET회원 등록 /members -> POST회원 조회 /members/{id} -> GET회
1xx (Informational): 요청이 수신되어 처리중2xx (Sucessful): 요청 정상 처리3xx (Redirection): 요청을 완료하려면 추가 행동이 필요4xx (Client Error): 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수
300 Multiple Choices301 Moved Permanently302 Found303 See Other304 Not Modified307 Temporary Redirect308 Permanent Redirect웹 브라우저는 3xx 응답의 결과에 Locatio
클라이언트의 요청에 잘못된 문법 등으로 서버가 요청을 수행할 수 없음오류의 원인이 클라이언트에 있음⭐ 중요! 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에 똑같은 재시도가 실패함 (5xx 오류는 서버가 고쳐지면 클라이언트 요청은 추후 성공 가능, ex)데