인터넷에서 컴퓨터 통신 방법 로컬 연결인 경우 케이블 연결로 바로 통신하면 된다 인터넷 연결인 경우 수많은 중간노드(서버)를 거쳐서 통신 -> 규칙 필요 어떤 규칙으로 노드를 거쳐서 메세지를 보내나? -> IP(인터넷 프로토콜) IP(인터넷 프로토콜) ![](ht
인터넷 프로토콜 4계층 데이터 전송 과정 채팅 프로그램으로 Hello, world! 메세지를 보내는 과정 Ethernet frame : 맥주소같은 물리적 정보 포함
클라이언트에서 여러 애플리케이션과 통신할 때어느 애플리케이션의 패킷인지 구분해야한다. -> PORT 사용!IP : 목적지 서버 찾기PORT : 서버의 특정 애플리케이션 찾기0 ~ 65535 할당 가능0 ~ 1023: 잘 알려진 포트, 사용하지 않는 것이 좋음FTP -
IP는 기억하기 어렵다.IP는 변경될 수 있다.전화번호부 역할 -> 전화번호부같은 중간 서버가 존재도메인 명을 IP주소로 변환
Uniform : 리소스를 식별하는 통일된 방식Resource : 자원, URI로 식별할 수 있는 모든 것Identifier : 다른 항목과 구분하는데 필요한 정보URI는 로케이터(Locator), 이름(Name) 또는 둘 다 추가로 분류될 수 있다.URL : 리소스가
1. HTTP 요청 메세지 생성 DNS 조회로 서버IP획득 Port 정보 획득 and URI의 resource, query 정보로 http 요청 메세지 생성 2. HTTP 메세지 전송
HTTP HTTP : HyperText Transfer Protocol 전송 가능 데이터 HTML, TEXT IMAGE, 음성, 영상, 파일 JSON, XML (API) 등등 거의 모든 데이터 서버 간 데이터 주고 받을 때도 대부분 HTTP
회원 목록 조회회원 조회회원 등록회원 수정회원 삭제앱 개발시 서버에서 API와 URL을 설계한다고 가정한다uri : uniform resource ldentifier계층형 구조로 설계회원 목록 조회 /read-member-list회원 조회 /read-member-by-
HTTP 메서드의 종류 HTTP 메서드 : 클라이언트가 서버에 요청할 때 기대하는 행동 주요 메서드 GET : 리소스 조회 POST : 요청 데이터 처리, 주로 등록 -> 클라이언트가 데이터를 담아서 줘야함 PUT : 리소스를 대체, 해당 리소스가 없으면 생성 PATC
호출해도 리소스를 변경하지 않는다. -> 변경이 일어나는 메서드는 안전하지 않음GET : 안전함POST, PUT : 안전하지 않음Q : 그래도 계속 호출해서, 로그 같은게 쌓여서 장애가 발생한다면? -> 서버에는 로그를 쌓는다.A : 안전은 해당 리소스만 고려, 그런
클라이언트에서 서버로 데이터 전송 1. 쿼리 파라미터를 통한 데이터 전송 GET 주로 정렬 필터(검색어, 게시판에 정렬 조건) 2. 메시지 바디를 통한 데이터 전송 POST, PUT, PATCH 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 클라이언트에서 서버로
설계 예시 HTTP API - 컬렉션 POST 기반 등록 ex) 회원 관리 API 제공 HTTP API - 스토어 PUT 기반 등록 ex) 정적 컨텐츠 관리, 원격 파일 관리 HTML Form 사용 웹 페이지 회원 관리 GET, POST만
상태코드 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능 1XX (informational): 요청이 수신되어 처리중 -> 거의 안보임 2XX (SUccessful): 요청 정상 처리 3XX (Redirection): 요청을 완료하려면 추가 행동이 필요 -
field-name":" OWS field-value OWSfield-name 대소문자 구분 XHTTP 전송에 필요한 모든 부가정보메시지 바디 내용, 메시지 바디 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보표준 헤더 많음!사용자 지정 헤더 추가
협상(콘텐츠 네고시에이션) 클라이언트가 선호하는 표현 요청 Accept: 클라이언트가 선호하는 미디어 타입 전달 Accept-Charset: 클라이언트가 선호하느 문자 인코딩 Accept-Encording: 클라이언트가 선호하는 압축 인코딩 Accept-Language
한번에 요청하고 한번에 다 받는다!추가로 Content-Encoding 정보 필요Transfer-Encoding: chunked 추가해야한다5바이트 전달 and 5바이트 전달 .... -> 따로 따로 받을 수 있다.Content-Lenght 있으면 안된다!범위를 지정해
Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답)Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달로그인 한 정보로 응답 받고 싶지만 요청 정보에 없음HTTP는ㄴ Stateless이기 때문에쿼리 파라미터롤 넘기는 방법도 있
이미 있는 데이터를 다시 네트워크를 통해 전달받고 있다.데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야한다.인터넷 네트워크는 매우 느리고 비싸다.브라우저 로딩 속도가 느리다.느린 사용자 경험캐시 저장소가 생김응답 결과를 캐시에 저장한다.캐시 저
캐시 유효 시간이 초과해서 서버에 다시 요청하면 다음 두가지 상황이 나타난다.서버에서 기존 데이터를 변경함서버에서 기존 데이터를 변경하지 않음캐시 만료후에도 서버에서 테이터를 변경하지 않음생각해보면 테이터를 전송하는 대신에 저장해 두었던 캐시를 재사용 할 수 있다.단
Cache-Control: 캐시 제어Pragma: 캐시 제어(하위 호환)Expires: 캐시 유효 기간(하위 호환)Cache-Control: max-age캐시 유효 시간, 초 단위Cache-Control: no-cache데이터는 캐시해도 되지만, 항상 orgin 서버에
직접 접근 시 응답속도가 너무 느리다 -> 머니까응답 시간 빨라짐처음 데이터에 접근하는 클라이언트는 응답 느릴 수 있다 -> 아직 캐시 되지 않았으니까Cache-Control: public응답이 public 캐시에 저장되어도 됨Cache-Control: private응