일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- AOP
- 허브
- ansible
- Jenkins
- Collection
- docker
- mybatis
- gradle
- Linux
- sonarQube
- jdk
- container
- Set
- 소켓
- map
- DevOps
- Pipeline
- JPA
- LAN어댑터
- post
- 방화벽
- tomcat
- cloud
- IntelliJ
- 라우터
- 캐시서버
- 액세스회선
- STREAM
- Spring
- Java
- Today
- Total
목록connect (2)
거북이-https://velog.io/@violet_evgadn 이전완료
서버 접속 ◎ 서버 접속이 필요한 이유 클라이언트 쪽에 소켓을 만들었으니 웹 서버 쪽에 존재하는 소켓과 연결하는 과정이 필요하다. 이는 Socket 라이브러리의 "connect" 함수를 통해 수행할 수 있다. 그런데 생각해 보자. 과연 이 연결하는 과정이 왜 필요할까? 이미 클라이언트 PC와 웹 서버가 존재하는 컴퓨터는 케이블로써 연결되어 있는 상태이므로 언제든 통신이 가능한 상태이다. 즉, 물리적으로 이미 통신을 보낼 수 있는 상황에서 왜 소켓을 만들고 소켓끼리 연결하는 과정이 필요할까? 이를 알기 위해선 애플리케이션 프로그램 사이에서 데이티 송/수신을 진행할 때 "프로토콜 스택"을 사용한다는 것을 알아야 한다. 소켓을 만든 직후 애플리케이션에서 데이터 송신을 수행할 경우 프로토콜 스택은 어떤 상황일까..
데이터 송/수신 동작 개요 ◎ 개요 이제 브라우저는 Request Message도 만들었고 OS에 메시지 송신을 의뢰하기 위해 IP 주소도 찾아냈다. 남은 것은 브라우저 측에서 OS 내부에 있는 프로토콜 스택에 데이터(Request Message)를 목적지(웹 서버 IP 주소)까지 보내달라고 의뢰하는 단계이다. OS 내부 프로토콜 스택에 메시지 송신을 의뢰할 때에도 이전에 사용했던 "Socket 라이브러리"를 활용한다. 하지만 IP 주소를 조회할 때는 메서드 1개(gethostbyname)만 사용한 것과 반면에 이 단계에선 여러 개의 메서드를 순서대로 사용해야 한다. 즉, OS 내부 프로토콜에 메시지 송신을 의뢰할 때는 라이브러리에 존재하는 복수의 프로그램을 결정된 순번대로 실행시켜야 하기 때문에 훨씬 ..