✅ 캐시 기본 동작 캐시가 없을 때 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 함 인터넷 네트워크는 매우 느리고 비싸다. 브라우저 로딩 속도가 느리다. 느린 사용자 경험 캐시 적용 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다. 비싼 네트워크 사용량을 줄일 수 있다. 브라우저 로딩 속도가 매우 빠르다. 빠른 사용자 경험 캐시 시간 초과 캐시 유효시간이 초과하면, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다. 이때 다시 네트워크 다운로드가 발생한다. ✅ 검증 헤더와 조건부 요청1 캐시 시간 초과 캐시 유효 시간이 초과해서 서버에 다시 요청하면 다음 2가지 상황이 나타난다. 서버에서 기존 데이터를 변경함 서버에서 기존 데이터를 변경하지 않음 캐시 만료 후에도 서버에서 데이터를 변경하지 않음 생각해보면 데이터를 전송하는 대신에 저장해 두었던 캐시를 재 사용 할 수 있다. 단 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인…

✅ HTTP 협상 협상(클라이언트가 선호하는 표현 요청) : 클라이언트가 선호하는 미디어 타입 전달 : 클라이언트가 선호하는 문자 인코딩 : 클라이언트가 선호하는 압축 인코딩 : 클라이언트가 선호하는 자연 언어 —> 협상 헤더는 요청시에만 사용 협상과 우선순위 1 Quality Values(q) 값 사용 0 ~ 1 : 클수록 높은 우선순위 생략 하면 1 Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7 우선 1) ko-KR;q=1(q생략) 우선 2) ko;q=0.9 우선 3) en-US;q=0.8 우선 4) en:q=9.7 협상과 우선순위 2 구체적인 것이 우선 함. Accept: 우선 1) text/plain;format=flowed 우선 2) text/plain 우선 3) 우선 4) 협상과 우선순위 3 구체적인 것을 기준으로 미디어 타입을 맞춤 Accept: , text/html;q=0.7, text/html;level=1, t…

✅ HTTP 표현 방법 Content-Type: 표현 데이터의 형식 Content-Encoding: 표현 데이터의 압축 방식 Content-Language: 표현 데이터의 자연 언어 Content-Length: 표현 데이터의 길이 표현 헤더는 전송, 응답 둘다 사용 Content-Type(표현 데이터의 형식 설명) 미디어 타입, 문자 인코딩 ex) text/html; charset=utf-8 ex) application/json ex) image/png Content-Encoding(표현 데이터 인코딩) 표현 데이터를 압축하기 위해 사용 데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제 ex) gzip, deflate, identity(압축안함) Content-Language(표현 데이터의 자연 언어) 표현 데이터의 자연 언어를 표현 ex) ko, en, en-US Content-Length(표현 데이터의 길이) 바이트 단위 …

✅ HTTP 헤더 개요 HTTP 헤더 header-field = field-name ”:” OWS field-value OWS (OWS:띄어쓰기 허용) field-name은 대소문자 구문 없음 HTTP 헤더 용도 HTTP 전송에 필요한 모든 부가정보 ex) 메시지 마디의 내용, 메시지 바다의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 등 표준 헤더가 너무 많음 필요시 임의의 헤더 추가 기능 ex) helloworld: hihi HTTP 헤더 분류 - 과거(RFC2616) General 헤더: 메시지 전체에 적용되는 정보 ex) Connection: close Request 헤더: 요청 정보 ex) User-Agent: Mozilla/5.0 Response 헤더: 응답 정보 ex) Server: Apache Entity 헤더: 엔티티 바디 정보 ex) Content-Type: text/html, Content-Length: 3423 HTTP Body - 과거…

✅ 2XX(Successful) 클라이언트의 요청을 성공적으로 처리 200 OK 201 Created 요청 성공해서 새로운 리소스가 생성됨 Location이 Header에 있을 수 있음 202 Accepted —> 요청이 접수되었으나 처리가 완료되지 않았음 배치 처리 같은 곳에서 사용 ex) 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리함 204 No Content 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음 ex) 웹 문서 편집기에서 버튼 —> 버튼의 결과로 아무 내용이 없어도 된다. —> 버튼을 눌러도 같은 화면을 유지해야 한다. —> 결과 내용이 없어도 204 메시지(2XX)만으로 성공을 인식할 수 있다. ✅ 3XX(리다이렉션) 요청을 완료하기 위해 유저 에이전트의 추가 조치 필요 300 Multiple Choices 301 Moved Permanently 302 Found 303 See Other 304 Not Modifie…

✅ HTTP 상태코드 상태 코드: 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능 1XX : 요청이 수신되어 처리 중(Informational) —> 2XX : 요청 정상 처리(Successful) 3XX : 요청을 완료하려면 추가 행동이 필요(Redirection) 4XX : 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음 5XX : 서버 오류, 서버가 정상 요청을 처리하지 못함(Server Error) Q) 만약 모르는 상태 코드가 나타나면? 클라이언트가 인식할 수 없는 상태코드를 서버가 반환하면? 클라이언트는 상위 상태코드로 해석해서 처리 미래에서 새로운 상태 코드가 추가되어도 클라리언트를 변경하지 않아도 됨 ex) 299 ??? —> 2XX : ex) 451 ??? —> 4XX : ex) 599 ??? —> 5XX : ✅ HTTP 상태코드 상태 코드: 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능 Q) 만약 모르는 상태 …

✅ HTTP API 설계 HTTP API - 컬렉션 POST 기반 등록 ex) 회원 관리 API 제공 HTTP API - 스토어 PUT 기반 등록 ex) 정적 컨텐츠 관리, 원격 파일 관리 HTML FORM 사용 웹 페이지 회원 관리 GET, POST만 지원 1. 회원 관리 시스템: API 설계 - POST 기반 등록 회원 목록 —> GET 회원 등록 —> POST 회원 조회 —> GET 회원 수정 —> PATCH, PUT, POST 회원 삭제 —> DELETE 2. 회원 관리 시스템: POST - 신규 자원 등록(실무에서 사용) 클라이언트는 등록될 리소스의 URI를 모른다. 회원 등록 —> POST POST 서버가 새로 등록된 리소스 URI를 생성해준다. HTTP/1.1 201 Create Location: 컬렉션 서버가 관리하는 리소스 디렉토리 서버가 리소스의 URI를 생성하고 관리 여리서 컬렉션은 3. 파일 관리 시스템: API 설계 - PUT 기반 등록 파일 목록…

✅ 클라이언트에서 서버로 데이터 전송 1. 데이터 전달 방식은 크게 2가지 쿼리 파라미터를 통한 데이터 전송 GET ex) 주로 정렬 필터(검색어) 메시지 바디를 통한 데이터 전송 POST, PUT, PATCH ex) 회원가입, 상품주문, 리소스 등록, 리소스 변경 2. 4가지 상황 정적 데이터 조회 이미지, 정적 테스트 문서 쿼리 파라미터 미사용(리소스 경로로 단순하게 조회 가능) 조회는 GET 사용 동적 데이터 조회 주로 검색, 게시판 목록에서 정렬 필터(검색어) 조회는 GET 사용 GET은 쿼리 파라미터 사용해서 데이터를 전달 HTML Form을 통한 데이터 전송 HTML Form Submit시 POST 전송 ex) 회원 가입, 상품 주문, 데이터 변경 사용 form의 내용을 메시지 바디를 통해서 전송(key-value, 쿼리 파라미터 형식) 전송 데이터를 Url encoding 처리 ex) abc김 —> abc%EA%B9%80 HTML Form은 GET 전송도 가능 주의…

✅ HTTP 메서드의 속성 1.안전 호출해도 리소스를 변경하지 않는다. Q) 그래도 계속 호출해서, 로그 같은게 쌓여서 장애가 발생하면요? —> 안전은 해당 리소스만 고려한다. 그런 부분까지 고려하지 않는다. 2.멱등 한 번 호출하든, 두 번 호출하든 100번 호출하든 결과가 똑같다. 멱등 메서드 GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다. PUT: 결과를 대체한다. 따라가 같은 요청을 여러번 해도 최종 결과는 같다. DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다. POST: 멱등이 아니다!!! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다. 활용 자동 복구 메커니즘 서버가 TIMEOUT 등으로 정상 응답을 못주었을 때, 클라이언트가 같은 요청을 다시 해도 되는가에 대한 판단 근거가 됨 재 요청 중간에 다른 곳에서 리소스를 변경해버리면? 사용자1: GET —> userName: A, age: 20 사용자2: PUT —> …

✅ PUT 리소스를 대체 리소스가 있으면 대체(기존거 삭제됨) 리소스가 없으면 생성 쉽게 이야기해서 덮어버림 중요! 클라이언트가 리소스를 식별 클라이언트가 리소스 를 알고 URI 지정 POST와 차이점 ✅ PATCH 리소스 부분 변경 클라이언트에서 요청 서버() ✅ DELETE 리소스 제거 ✅ PUT ✅ PATCH ✅ DELETE

✅ HTTP 메서드 종류: 주요 메서드 : 리소스 조회 : 요청 데이터 처리, 주로 등록에 사용 : 리소스를 대체, 해당 리소스가 없으면 생성 : 리소스 부분 변경 : 리소스 삭제 ✅ HTTP 메서드 종류: 기타 메서드 : GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환 : 대상 리소스에 대한 통신 가능 옵션(메서드)를 설명(주로 에서 사용) : 대상 자원으로 식별되는 서버에 대한 터널을 설정 —> 거의 사용 X : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행 —> 거의 사용 X ✅ GET 리소스 조회 서버에 전달하고 싶은 데이터는 Query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음 ✅ POST 요청 데이터 처리 메시지 바디를 통해 서버로 요청 데이터 전달 서버는 요청 데이터를 처리 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.…

✅ HTTP API를 만들어보자 HTTP API를 만들어보자 HTTP 메서드 - GET, POST HTTP 메서드 - PUT, PATCH, DELETE HTTP 메서드의 속성 요구사항 ex) 회원 정보 관리 API를 만들어라 회원 목록 조회 회원 조회 회원 등록 회원 수정 회원 삭제 API URL 설정: 초보 개발자 회원 목록 조회 : 회원 조회 : 회원 등록 : 회원 수정 : 회원 삭제 : —> 이것은 좋은 URI 설계일까? —> 가장 중요한 것은 리소스 식별 API URI 고민 리소스의 의미는 뭘까? 회원을 등록하고 수정하고 조회하는게 리소스가 아니다! ex) 미네랄을 캐라 —> 미네랄이 리소스 회원이라는 개념 자체가 바로 리소스이다. 리소스를 어떻게 식별하는게 좋을까? 회원을 등록하고 수정하고 조회하는 것을 모두 배제 회원이라는 리소스만 식별하면 된다. —> 회원 리소스를 URI에 매핑 API URL 설정: 위 상황 고려 목록 조회 : 조회 —> 어떻게 구분하…

✅ HTTP 메세지 시작 라인: 요청 메시지 start-line = request-line / status-line request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터) HTTP 메서드 (GET: 조회) 종류 : GET, POST, PUT, DELETE 서버가 수행해야 할 동작 지정 : GET(리소스 조회), POST(요청 내역 처리) 요청 대상() HTTP Version 시작 라인: 요청 메시지(요청대상) 절대경로 = 로 시작하는 경로 시작 라인: 응답 메시지 start-line = request-line / status-line status-line = HTTP-version SP status-code SP reason-phrase CRLF HTTP 상태 코드 : 요청 성공, 실패를 나타냄 200 : 성공 400 : 클라리언트 요청 오류 500 : 서버 내부 오류 이유 문구 : 사람이 이해할 수 있는 짧은…

✅ 클라이언트 서버 구조 Request - Response 구조 클라이언트는 서버에 요청을 보내고, 응답을 대기 서버가 요청에 대한 결과를 만들어서 응답 각각 역할을 나뉘었다는 것이 포인트 클라이언트는 UI/UX에 집중하고, 서버는 비즈니스 로직이나, 데이터만 관리 이렇게 독립적으로 분리하면 각각 고도화 진행 가능 또한 문제가 발생하면 각각 독립적으로 처리만 하면 됨 ✅ 무상태 프로토콜 = Stateless 서버가 클라이언트의 상태를 보존 X 상태 유지(stateful) ex) 중간에 다른 점원이 바뀌면 안됨(만약에 바뀌면 상태 정보를 다른 점원에게 미리 알려줘야 함) 상태 유지 X(무상태) ex) 점원이 바뀌어도 정확하게 결과를 얻을 수 있음, 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입 가능, 응답 서버를 쉽게 바뀔 수 있음(무한 서버 증설 가능) 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있음 응답 서버를 쉽게 바뀔 수 있음(무한한 서버 증설 가능) 장점…

✅ HTTP 1. HTTP 메시지에 모든 것을 전송 HTML, TEXT Image, 음성, 영상, 파일 JSON, XML(API) 거의 모든 형태의 데이터 전송 가능 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용 2. HTTP 역사 HTTp/0.9 1991년 : GET 메서드만 지원, HTTP 헤더 X HTTP/1.0 1995년 : 메서드, 헤더 추가 HTTP/1.1 1997년 : 가장 많이 사용, 우리에게 가장 중요한 버전 HTTP/2 2015년 : 성능 개선 HTTP/3 진행중 : TCP 대신 UDP 사용, 성능 개선 3. 기반 프로토콜 TCP: HTTP/1.1, HTTP UDP: HTTP/3 점점 HTTP/2, HTTP/3도 점점 증가 4. HTTP 특징 클라이언트 서버 구조 무상태 프로토콜, 비연결성 HTTP 메시지 단순함, 확장 가능 ✅ HTTP 1. HTTP 메시지에 모든 것을 전송 2. HTTP 역사 3. 기반 프로토콜 4. HTTP 특징

✅ URI 의미 (리소스 식별하는 통일된 방식) (자원, URI로 식별할 수 있는 모든 것, 제한 없음) (다른 항목과 구분하는데 필요요한 정보 ✅ URL, URN 의미 URL(Uniform Resource Locator): 리소스의 위치. URN(Uniform Resource Name): 리소스의 이름. ex) urn:isbn:8969777331(어떤 책의 isbn URN) 참고 위치(Locator)는 변할 수 있지만, 이름(Name)은 변하지 않음. ✅ URL 문법 ex) https://www.google.com:443/search?q=hello&hI=ko 프로토콜 : https 호스트명 : www.google.com 포트 번호 : 443 패스 : /search 쿼리 파라미터 : q=hello&hi=ko Scheme 주로 프로토콜 사용 프로토콜 : 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙 ex) http, https, ftp 등 http는 80포트, https는 4…

✅ 1. 인터넷 통신 클라이언트에서 특정 요청을 하면 서버에서 요청을 확인하고 다시 클라이언트에서 보내주는 방식. 클라이언트와 서버를 연결해주는 무수한 연결망을 인터넷이라고 함. ✅ 2. IP(Internet Protocol) IP 역할 클라이언트 IP와 서버 IP를 명시해서 정확한 위치에 원하는 요청을 함 지정한 IP(IP Address)에 데이터 전달 패킷(Packet)이라는 통신 단위로 데이터 전달 —> 패킷은 약간 편지 같은거? 보내는사람, 받는 사람 적어서 보내는 것처럼 데이터를 전달 할 때 이 존재 서버 패킷 전달 인터넷을 통해 서버(주소)에게 데이터를 전달하는데, 다시 서버에서 클라이언트에게 전달 될 때에는 같은 경로로 오지 않을 수 있음. IP 프로토콜의 한계 —> TCP, UDP로 해결 가능 : 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송 : 중간에 패킷이 사라지면? 패킷이 순서대로 안오면? : 같은 IP를 사용하는 서버에서 통신하는 App이 둘 2상…