소켓 = 서버 : Application
사진 전송) BufferedReader로 사진 파일을 읽어서 바이트로 변환해서 전송
Application에서 OS로 내려가는 선이 ByteStream이니까 Byte 단위로 변환해서 전송
논문
- 컴퓨터 프로그램으로 작성
- 각자의 프로그램들이 다 달라서 통일시켜야 같은 프로그램으로 논문을 읽을 수 있음
→ 툴(Write, Read)
- 언어도 공용어(영어)로 통일을 해야 논문을 읽을 수 있음
브라우저
- 팀 버너스리가 논문 툴(브라우저:Read)을 만듦
작성은 자신들이 평소에 쓰는 툴로 작성하면 됨
- 바이트의 모임이 문자열
문자열을 받아서 그대로 해석만 하면 됨
- 툴에서 마크업을 달아서 표시(굵기, 기울기 등)
마크업 : 글자를 의미있게 표시하는 것
코드 블록을 마크업으로 감싸서 보여주는 방법
대표적 : html
프레임 텍스트 : 평문
약 20개 뿐 → 논문에 필요한 태그들을 마크업으로 만듦
예시) <h1> 안녕 </h2>
헤딩1 : 글자를 표시하라
예시) <u> 안녕 </u>
확장자 .html(Hypertext Markup Language)
- html의 브라우저가 예쁘게 렌더링해서 보여주는 역할
** 이미지를 실제로 그려내는 과정
- Hypertext : 내 페이지가 적혀있는 글자가 사라지고 새로운 페이지로 덮어 씌워지는 것
- 브라우저 화면이 1개라 1장은 보이나 다음장을 볼 수 없음
→ 스크롤을 만들어 모든 장을 다 볼 수 있음
- 각주가 다 달려있어야 함
단어의 설명, 출처 밝히는 것들
<a> <a> : 링크 → 내 페이지가 적혀있는 글자가 사라지고 새로운 페이지로 덮어씌워지는 것
HTML 통신 과정
- 요청(Request) 단계
- 사용자가 웹 브라우저를 통해 특정 웹 페이지에 접속
- 브라우저는 해당 페이지의 URL을 서버에게 요청
HTTP 프로토콜을 통해 이루어짐
요청 메서드(GET, POST 등)와 함께 필요한 헤더 및 데이터가 전송
- 서버 처리 단계
- 서버는 클라이언트의 요청을 받아들이고, 해당 요청에 대한 처리를 시작.
- 서버는 필요한 데이터베이스 조회, 비즈니스 로직 실행, 혹은 정적 파일(HTML, CSS, JavaScript 등)을 찾아 응답
- 응답(Response) 단계
- 서버는 클라이언트에 대한 응답을 생성
- 상태 코드(200 OK, 404 Not Found 등), 헤더 정보, 응답 본문으로 구성된 HTML 등
- 응답은 HTTP 응답 메시지를 통해 클라이언트로 전송
- 클라이언트 처리 단계
- 브라우저는 서버로부터 받은 응답을 처리
- 응답에 포함된 HTML 문서는 브라우저에 의해 파싱
필요한 경우 HTML 문서를 렌더링하여 사용자에게 보여줌
CSS 및 JavaScript와 함께 웹 페이지를 완성합니다.
- 페이지 렌더링 단계
- 브라우저는 받아온 HTML 문서를 파싱
- JavaScript 코드가 포함되어 있으면 해당 코드도 실행되어 동적인 페이지 요소를 조작하거나 추가적인 데이터 요청을 할 수 있음
DOM(Document Object Model)을 생성
CSS 파일과 함께 스타일을 적용
- 자원 요청 및 응답 (옵션)
- HTML 문서에 포함된 외부 리소스(이미지, 스타일시트, 스크립트 파일 등)는 브라우저에 의해 각각 별도로 요청
서버는 각 요청에 대한 응답을 전송
이러한 자원들은 브라우저에 의해 캐시되어 향후 요청 시 재사용
- 클라이언트 1명 당 스레드 1개가 필요함
업무를 처리하고 스레드가 없어지지 않으면 CPU가 낭비됨
- 모든 웹 서버는 스레드 풀이 필요함
사용 가능한 스레드 풀을 미리 만들어놓음
삭제할 필요도 없고 만들 필요도 없음
- 요청이 오면 heap을 사용
요청자 : IP주소, Port가 필요함
웹 서버는 80으로 포트가 통일되어 있음
연결 소켓이고 내부적으로 포트가 생겨서 통신할 것 / 서로 소켓이 생김
요청 시 BufferedWriter에 들어갈 것 : URL
(프로토콜, IP주소, PORT 번호, 자원명)
뭘 달라는 것인지 알 수 없으니 프로토콜이 필요함
프로토콜 없이는 전화로 인간만 통신을 할 수 있음
HTTP : 8천개 프로토콜 하나 당 10페이지
htt://IP 주소 : 포트 번호/자원 명
브라우저에 안 적어도 되는 이유: default 값
- 자원 명만 파싱함
BufferedReader로 읽은 전체 데이터 중에 찾는 자원 명만 남음
- 버퍼를 달아서 HDD에 있는 파일 읽음
- 다시 BufferedWriter에 담아서 클라이언트한테 전송
- BufferedReader로 읽어 그림을 그림
파일을 필요로 하는 자 : 클라이언트
파일을 들고 있는 자 : 서버
요청은 브라우저를 사용함
예시
내가 url을 줄테니까 자원명을 찾아서 응답해줘
주소를 주소창에 입력 > url 생성> 소켓이 생성 > BufferedWriter> 연결 > 새로운 소켓 생성 > 자원명으로 파싱 > 하드드디스크에 파일을 읽음 / BufferedReader로 읽기 > BufferedWriter에 담아서 점송 > BufferedReader로 읽기 > 브라우저로 랜더링 하기
- get 요청 : 일반인들은 모르기 때문에 브라우저로 요청만 하면 응답이 오고 랜더링됨
- 요청하는 내용 : 자원명(html)
프로토콜을 만들어서 지켜야할 문서를 만듦 → RFC
점점 공유하는 파일이 다양해지고 더 많은 사람들과 통신하다보니 서로 맞추기 위한 약속이 필요함
정확하게 어떻게 보낼 것인지 정해야 IF문에서 어떻게 설정해서 파싱할 것인지 처리 하기 위해 통일성있게 정하는 것이 MIME 타입임
Body에 데이터가 있음
GET 요청 시에는 필요없으나 GET에 대한 응답 시에는 필요함
MIME 타입 형태 : 대제목/소제목
자주 쓰는 것 외우기!
- application/json
- application/x-www-form-urlencoded
- text/html
- text/plain
MIME 타입 찾는 방법
1) 챗GPT한테 문의하기
2) ctrl + F 검색하기
Share article