The technical answer could be to make that socket a field in your test class, and then have a @BeforeAll public static void setUp() method that creates the required object once. Or a @Before public void setUp() that starts the server before every test case. And of course, you would need matching @AfterAll resp. @After methods. As the other answer outlines, you can use a ProcessBuilder for example, to start a completely own process.
But then: a "real" unit test should only rely on your source code. A dependency such as here, that requires an external component/service to be available rather renders these functional or integration tests.
So, the real answer would be: step back. Look at your server code, and ask yourself whether you really need to run the whole server in order to tests its parts.
Meaning: in the end, a "server" is about making some "business logic" available to the outter world. Those are two different concerns, and they should be addressed differently.
So: you write unit tests for your business logic that can all be nicely tested without any server around. And then you write more of an integration test that tests whether your server is correctly "coupled" with the business logic part.
In other words: assume your server offers 3 different services, and each one service has multiple parameters, and "paths" of execution. You absolutely do not test all these services, with all paramater variations and all "paths" by going through your server. Instead, you write your code so that you can test each service completely without spinning up the server for each test. And then, when all of that works, you write a few tests that ensure that each service can be called using the server (and there you focus on very different aspects, like: "are the parameters passed to the service showing up *inside", or "are errors within the business logic processed as expected by the server").